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BACKGROUND 

The described technology relates generally to accessing data and 
particularly to accessing data from data sources with diverse formats. 

Large organizations may have their digital data stored in various data 
stores, such as databases and file systems, in diverse and incompatible formats. 
Different groups within the large organizations may have created their own data 
stores to meet the needs of the group. Each group would typically select its own 
type of data storage system and format to meet its particular needs. Traditionally, 
these data stores were created independently of any other data stores within the 
organization. As a result, the various data stores of an organization often 
contained duplicate and inconsistent data. 

Recently, these large organizations have adopted standards such as the 
extensible markup language ("XML") for representing data in a uniform format. 
The use of XML by each group within an organization increases the compatibility 
of the data stores. It is, however, difficult for organizations to provide an XML 
interface to each of its existing data stores. The organizations would need to 
expend considerable resources to provide a mapping between their existing data 
stores or other sources of data and the XML formats. 
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It would be desirable to have a system that would facilitate the integrating 
of data stores with incompatible formats. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 illustrates the schema of this XML document. 
5 Figure 2 represents a Joinln graph (JIG) for the match expression of Table 

8. 

Figure 3 is a block diagram illustrating the overall organization of an 
execution program generated by the data integration engine. 

Figure 4 is a block diagram illustrating the function to generate an 
10 execution program. 

Figure 5 is a flow diagram illustrating processing of the generate extract 
program function in one embodiment. 

Figure 6 is a flow diagram illustrating the processing of the generate extract 
plan function in one embodiment. 
15 Figure 7 is a flow diagram illustrating processing of the match expression 

function in one embodiment. 

Figure 8 is a flow diagram illustrating the processing of the create Joinln 
graph function in one embodiment. 

Figure 9 is a flow diagram illustrating processing of the generate Joinln 
20 graph into one embodiment. 

Figure 10 illustrates the tables of the data store. 

Figure 1 1 illustrates the results of the sorted outer union for the tables of 
Figure 10. 

Figure 12 illustrates the SQL query for each of the tables of Figure 10 paid 
25 to generate the sorted outer union. 

Figure 13 is a flow diagram illustrating the processing of generating a 
sorted outer union. 



[33729-8001 /SL01 2050.406] 



-2- 



8/1/01 



Bm&iS! JL'^W& . f O O'G :l O J., 



Figure 14 is a flow diagram illustrating processing of a generate SQL query 
function in one embodiment. 

Figure 15 is a block diagram illustrating an extract program. 
Figure 16 is a flow diagram that illustrates code of a join node of an extract 
5 program in one embodiment. 

Figure 17 illustrates the output of the nodes of the extraction plan to Figure 

15. 

Figure 18 illustrates a final NCR structure. 
Figure 19 illustrates the Correspondence Tree. 

10 DETAILED DESCRIPTION 

S A method and system for providing data integration of multiple data stores 

^ with diverse formats is provided. In one embodiment, the data integration engine 

~ accepts queries using a standard query language such as XML-QL, executes those 

.g queries against the multiple data stores, and returns the results. The data stores 

15 may include relational databases, hierarchical databases, file systems, application 
data available via APIs, and so on. A query may reference data that resides in 
different data stores. The data integration engine allows operations such as joins 
across multiple data stores. In one embodiment, the data integration engine uses 
XML as the data model in which the data from the various data stores is 
20 represented. The data integration engine processes a query by parsing the query 
into an internal representation, compiling and optimizing the internal 
representation into a physical execution representation, and then executing the 
execution representation. By providing a uniform and data model, the data 
integration engine allows access to data stores in diverse formats. 
25 In one embodiment, the data integration engine executes a query on a data 

store by first providing a mapping of the data store format into an XML format. 
The query for the data store is based on XML format. The data integration engine 
upon receiving a query, generates a native query for the data store from the 



m 
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received query using the provided mapping. The data integration engine then 
executes the native query to generate data in a native format needed to generate 
the results of the received query. The data integration engine then converts the 
data in the native format into data in a format referred to as nested conditional 

5 relations ("NCR"). The data integration engine then applies various operators 
(e.g., joins and unions) to the data in NCR format to generate the query results in 
an NCR format. The data integration engine then converts the results in the NCR 
format into an XML format. In this way, the integration engine can provide access 
to various data sources in different formats. 

10 A nested conditional relation is a table in which each row may have a 

different schema and each column is either a primitive type or a nested NCR. The 
schema of each row in an NCR is indicated by a tag, which can be considered to 
be the zero column of the row. For example, certain rows of the table may 
represent employees of a company and have columns named "first name," "last 

15 name," "phone number," and so on. Other rows in the table may represent 
departments within the company and have columns named "department name," 
"department head," and so on. The tag for a row indicates whether the row is an 
employee or a department row. A column for a certain type of row may itself 
contain a nested conditional relation. For example, an employee row may include 

20 a column named "skills" that contains a table with sub-rows containing 
information relating to computer skills and accounting skills of the employee. The 
table may itself be a nested conditional relation in that each sub-row may include a 
tag indicating whether the row represents a computer skill or an accounting skill. 
The nesting of nested conditional relations may occur to an arbitrary level. The 

25 NCR format is described below in detail. 

The following example illustrates a data store, a mapping for the data store, 
a query, an LMatch representation for the query, a Joinln graph for the query, and 
an SQL query used to retrieve the data from the data source. Tables 1-3 illustrate 
an example of data that is stored in a data store such as a relational database. The 
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relational database contains three tables: DEPARTMENTS table, EMPLOYEES 
table, and BUILDINGSDOCS table. 



TABLE 1 DEPARTMENTS 



Name 


Contact 


Finance 


E1247 


Engineering 


E3214 



TABLE 2 EMPLOYEES 



ID 


Fname 


Lname 


Dept 


Bids 


Office 


Manager 


E0764 


Bobby 


Darrows 


Finance 


B 


102 


El 247 


E0334 


Alice 


LeGlass 


Finance 


B 


103 


E1247 


E1247 


David 


Winston 


Finance 


B 


110 


NULL 


E3214 


David 


McKinzie 


Engineering 


L 


NULL 


E1153 


E0868 


Misha 


Niev 


Engineering 


L 


15 


E1153 


E0012 


David 


Herford 


Engineering 


M 


332 


E1153 


E1153 


Charlotte 


Burton 


Engineering 


M 


330 


E0124 


E0124 


David 


Wong 


Engineering 


L 


12 


NULL 



TABLE 3 BUILDINGSDOCS 



Building 


Office 


Phone 


MaintContact 


B 


102 


xll02 


E0764 


B 


103 


xll03 


E0764 


B 


110 


xlllO 


E0764 


L 


lobby 


xOOOl 


E3214 


L 


12 


x0120 


E3214 


L 


15 


x0150 


E3214 


M 


330 


x2330 


E3214 


M 


332 


x2332 


E3214 



The DEPARTMENTS table contains one row for each department of an 
organization. As illustrated by Table 1, the organization has a finance and an 
engineering department. The DEPARTMENTS table contains two columns: 

10 name and contact. The name column contains the name of the department, and the 
contact column contains the employee identifier of the contact person for the 
department. For example, the first row of the table indicates that the department is 
"finance" and that the contact employee is "E1247." The EMPLOYEES table 
contains a row for each employee in the organization. Each row includes seven 

15 columns: ID, Fname, Lname, Dept, Bldg, Office, and Manager. The ID column 
uniquely identifies the employee, the Fname column contains the first name of the 
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10 



15 



employee, the Lname column contains the last name of the employee, the Dept 
column identifies the employee's department, the Bldg column identifies the 
building in which the employee is located, the Office column identifies the 
employee's office within the building, and the Manager column identifies the 
employee's manager. The Dept column contains one of the values from the Name 
column of the DEPARTMENTS table. The BUILDINGSDOCS table contains a 
row for each office within each building of the organization. The 
BUILDINGSDOCS table contains four columns: Building, Office, Phone, and 
MaintContact. The Building column identifies a building, the Office column 
identifies an office within the building, the Phone column contains the phone 
number associated with that office, and the MaintContact column identifies the 
employee who is the maintenance contact for the office. The combination of the 
Building and Office columns uniquely identifies each row. The Bldg and Office 
columns of the EMPLOYEES table identifies a row within the 
BUILDINGSDOCS table. 

Table 4 is an example of data stored as an XML document. 



TABLE 4 



<deptlist> 

<deptname= "Finance" > 
<employec> 

<namc><first>Bobby</first><last>Darrows</last></name> 

<office phonc= M xll027> 
</employee> 
<cmployee> 

<name><first>Alice</first><last>LeGlass<Aast></name> 
Office phone="xll037> 
</employee> 

</dept> 

<dept name= "Engineering 1 ^ 
<employee> 

<name><first>David</first><last>McKinzie</last></name> 
</employee> 
<employee> 

<name><first>Misha</first><last>Niev</last></name> 
<office phone="x01507> 
</employee> 

</dept> 
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</deptlist> 



The XML document includes the root element <deptlist> that has a name 
attribute and that contains a <dept> element corresponding to each department 
within an organization. Each <dept> element contains an <employee> element for 
5 each employee within the department. Each <employee> element contains a 
<name> element and optionally an <office> element. The <name> element 
includes a <first> element and <last> element. The <office> element includes a 
phone attribute. The schema of an XML document may be represented by an 
XML data type definition ("DTD") of the document. Figure 1 illustrates the 
10 schema of this XML document. As this figure illustrates, the schema is specified 
as a tree-like hierarchy with the nodes of the tree having parent-child relationships. 
For example, node 104 is the parent of nodes 105 and 108, which are children of 
node 104. Node 101 corresponds to the <deptlist> element and has one child node 
102, which corresponds to the <dept> element. Node 102 has two child nodes, 
15 103 and 104. Node 104 corresponds to the name attribute of the <dept> element 
and node 104 corresponds to the <employee> element. Node 104 has two child 
nodes 105 and 108. Node 105 corresponds to the <name> element and has two 
child nodes 106 and 107. Node 106 corresponds to the <first> element, and node 
107 corresponds to the <last> element. Node 108 corresponds to the <office> 
20 element and has one child node 109, which corresponds to the phone attribute. 

The mapping technique is particularly useful in situations where a legacy 
database, such as the example database of Tables 1-3, is to be accessed using 
queries designed for XML data, such as the example of Table 4. The XML 
schema may be previously defined and many different applications for accessing 
25 data based on that XML schema may have also been defined. For example, one 
such application may be a query of the data. An example query for semi- 
structured data may be an XML transform that is designed to input data in XML 
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format and output a subset of the data in XML format. For example, a query for 
the database of Tables 1-3 may be a request to list the ID of each employee in the 
"Finance" department. The subset of that data that is output corresponds to the 
results of the query represented by the XSL transform. One skilled in the art 

5 would appreciate that queries can be represented in other formats such as XML- 
QL. When a legacy database is to be accessed, the data is not stored using XML 
format. Thus, in one embodiment, a query system inputs a semi-structured query 
and uses a mapping table to generate a structured query, such as an SQL query, 
that is appropriate for accessing the legacy database. The mapping technique for 

10 generating that mapping table is described in the following. 

Table 5 is a portion of the mapping table generated in accordance with the 
mapping technique that maps the XML schema of Table 4 to the legacy database 



of Tables 1-3. 

TABLE 5 



Row 


ParentName 


A/E 


ChildName 


Table 


Pkev 


Ckev 


1 


deptlist 


E 


dept 


DEPARTMENTS 




Name 


2 


dept 


A 


name 


DEPARTMENTS 


Name 


Name 


3 


dept 


E 


employee 


EMPLOYEES 


Dept 


ID 


4 


employee 


E 


name 


EMPLOYEES 


ID 


ID 


5 


name 


E 


first 


EMPLOYEES 


ID 


Fname 


6 


name 


E 


last 


EMPLOYEES 


ID 


Lname 


7 


employee 


E 


office 


EMPLOYEES 


ID 


{Bldg,Office} 


8 


office 


A 


phone 


BUILDINGSDOCS 


{Building,Office} 


phone 



15 

The mapping table contains one row for each parent-child relationship of 
the XML schema. The mapping is further described in U.S. Patent Application 
entitled "Method and Apparatus for Storing Semi-Structured Data in a Structured 
Manner." As shown in Figure 1, the XML schema defines eight parent-child 
20 relationships such as the relationship between node 102 and node 104. Thus, the 
mapping table contains eight rows. Each row uniquely identifies a parent-child 
relationship using the ParentName and ChildName columns. For example, the 
parent-child relationship of node 102 and node 104 is represented by row 3 as 



[33729-8001 /SL01 2050.406] 



-8- 



8/1/01 



indicated by the ParentName of "dept" and the ChildName of "employee." Each 
row maps the parent-child relationship to the table in the legacy database that 
corresponds to that relationship. In the example of row 3, the Table column 
indicates that the "dept-employee" relationship maps to the EMPLOYEES table. 

5 The query system could use only the ParentName, ChildName, and Table columns 
of the mapping table to generate a structured query from a semi-structured query. 
For example, if the legacy database had used the same column names as defined 
by the elements of the XML schema (e.g., "employee" rather than "ID"), then only 
these three columns would be needed to generate the structured query. For 

10 example, if the semi-structured query requested an identifier of all employees 
within the finance department and the DEPARTMENTS table contained an 
"employee" column rather than an "ID" column, then the query system could input 
a semi-structured query with only these three columns and generate a structured 
query. In the more general case where the columns of the legacy database are 

15 arbitrarily named, the mapping table includes a parent key column ("PKey") and a 
child key column ("CKey"). The parent key column contains the name of the 
column that identifies the parent of the parent-child relationship. The child key 
column contains the name of the column that identifies the child of the parent- 
child relationship. For example, in row 3, the parent is identified by the "dept" 

20 column and the child is identified by the "ID" column in the EMPLOYEES table. 
Thus, to generate the structured query to retrieve the ID of an employee within the 
finance department, the query that uses a select clause of 
EMPLOYEES. dept="Finance" would be used. Table 5 also includes a column 
named "A/E" to indicate whether the row corresponds to an element within the 

25 semi-structured data or an attribute of an element with semi-structured data. As 
illustrated by rows 7 and 8, some of the parent and child keys actually consist of 
multiple columns that uniquely identify a row in the corresponding table. For 
example, the rows of the BUILDINGSDOCS table are uniquely identified by a 
combination of the Building and Office columns. 
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The query system maps the selections within the semi-structured query to 
selections within a structured query. The following illustrates the basic format of 
that mapping when the structured query is an SQL format. 

SELECT {TABLE}. {CKEY} 
FROM {TABLE} 

WHERE {TABLE}. {PKEY} = pkey 

The TABLE, CKEY, and PKEY parameters are replaced by the 
corresponding values from the row in the mapping table for the parent-child 
relationships specified by the selection. In other words, this query will find all the 
children given the key for the parent. The following illustrates the format of the 
mapping when the query represents the identification of the idea of all employees 
within the finance department. 

SELECT EMPLOYEE S . ID 

FROM EMPLOYEES 

WHERE EMPLOYEE S . Dept = "Finance" 

The query system also allows chaining of keys to effectively navigate 
through the hierarchy defined by the semi-structured data. The query system uses 
the joint concept of relationship databases to effect this chaining of keys. The 
following illustrates chaining: 

SELECT { T ABLE2 } . { CKE Y2 } 
FROM { TABLE 1 } , {TABLE2} 

WHERE {TABLE 1}. {PKEY 1} = pkey && {TABLE1}.{CKEY1}= 
{ T ABLE2 } . {PKEY2 } 

The TABLE 1, PKEY1, and CKEY1 parameters are derived from the first 
parent-child relationship in the chain, and the TABLE2 , PKEY2, and CKEY2 
parameters are derived from the second parent-child relationship in the chain. The 
child key associated with the first parent-child relationship matches the parent key 
associated with the second parent-child relationship. The following is an example 
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of the chaining to identify the building for the employees of the finance 
department. 

SELECT BUILDINGSDOCS.BUILDING 

FROM EMPLOYEES, BUILDINGSDOCS WHERE EMPLOYEES = "Finance" && 
5 EMPLOYEES. BLDG = BUILDINGDOCS. BUILDING && 

EMPLOYEES. OFFICE = BUILDINGDOCS.OFFICE 

In one embodiment, the mapping table also contains the value rows 
corresponding to each leaf node, that is a node that is not a parent node. The leaf 
10 nodes of Figure 1 are nodes 103, 106, 107, and 109. In one embodiment, each 
value row identifies an XML element or attribute, the table in the legacy database 
that contains an element, and the name of the column in the table that contains the 
value for that element or attribute. Table 6 illustrates the four value rows for the 
mapping associated with Tables 1-3 and Table 4. 

15 TABLE 6 



Row 


A/E 


Name 


Table 


Key 


Value 


9 


A 


name 


DEPARTMENTS 


Name 


Name 


10 


E 


first 


EMPLOYEES 


Fname 


FName 


11 


E 


last 


EMPLOYEES 


Lname 


LName 


12 


A 


phone 


BUILDINGSDOCS 


Phone 


Phone 



The "A/E" column identifies whether the row is an attribute or element; the 
"Name" column identifies the name of the element and attributes; the "Table" 
column identifies the legacy table; the "Key" column identifies the key for that 
20 table; and the "Value" column identifies the name of the column where the value 
is stored. 

Table 7 illustrates a query that is to be applied to the data of Tables 1-3. 
The query indicates to return the first and last names and phone number of each 
employee in the engineering department. 
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Table 7 

WHERE 
<deptlist> 

<dept narne^ "Engineering'^ . 

<employee> 

<name><first>$first</first><last>$last</last></name> 

<office phone="$ph7> 

</emp!oyce> 

</dept> 

</deptlist> 

CONSTRUCT 

<employee><name>$last, $first</name><phone>$ph</phone></employee> 

The data integration engine generates a "match expression" for a logical 
match operation ("LMatch") for the query when compiling the query. The logical 

5 match operation supports operations for performing XML navigation. The match 
expression defines a tree of navigations. Each node of the tree indicates a 
navigation type (e.g., child, parent, or sibling), a navigation condition {e.g., a 
condition on the name of the child), whether the navigation is required, whether 
there should be a binding to the target of the navigation (i.e., a value returned with 

10 the specified name), and whether the result should be nested. 

Table 8 illustrates a match expression for the XML of Table 4 for the query 
of Table 7. Each row of Table 8 represents a different navigation path. For 
example, the first row represents a navigation path from the root of the deplist 
element to its child element of the dept element and then to the name attribute of 

15 the dept element. The remaining rows represent different branches on the tree. 
For example, the second row represents the branch of roo/(deplist), c/w7c/(dept), 
c/z/7<i(employee), child(nam6), and child(Gist). The symbols prefixed with "$" 
represent bindings. 



Table 8 



roo/(deptlist) 


chilcHde.pt) 


c/z/7ti(iiame,$auto 1) 










ch //^(employee) 


childipasno) 


child(first, $first) 










child(lasU Slast) 








child(offico) 


child(phom, $ph) 



Figure 2 represents a Joinln graph (JIG) for the match expression of Table 
8. The Joinln graph is a data structure that facilitates the optimization of the query 
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to be executed against the data store. This JIG indicates that the Departments, 
Employees, and Buildingdocs tables of the data store are to be joined together. 
This JIG also indicates the bindings (e.g., Sfirst) and the join columns (e.g., Name 
and Dept). The format of the JIG is described below in detail. The JIG is 
5 generated from the match expression using the mapping. The data integration 
engine then generates the query to be executed. The following query is generated. 

SELECT EMPLOYEE S . Fname, EMPLOYEES. Lname, BUILDINGSDOCS.phone 
FROM DEPARTMENTS, EMPLOYEES, BUILDINGSDOCS 
10 WHERE DEPARTMENTS . Name = EMPLOYEES. Dept AND 

EMPLOYEES. Bldg = BUILDINGDOC S Building AND 
EMPLOYEES. Office = BUILDINGSDOCS. Office AND 
DEPARTMENTS. NAME = "Engineering" 

15 Figure 3 is a block diagram illustrating the overall organization of an 

execution program generated by the data integration engine. An execution 
program consist of an extract program 310 and a construct program 320. A 
compiler of the data integration engine generates the execution program during a 
compilation phase. The extract program is a series of operations on a data 

20 extracted from the data sources. The extract program represents a graph of the 
operations. The leaf nodes 3 1 1 of the extract program represents a sorted outer 
union operation applied to the data stores 312. The compiler generates a query for 
each data store in the native query language of the data store to retrieve the results 
of the sorted outer union. The compiler generates the sorted outer union using the 

25 LMatch operation, Joinln graph, and mapping. During execution of the extract 
program, the generated query is applied to each data store. The construct program 
accesses the root node 313 of the extract program which retrieves the results 
generated by the extract program. The construct program collects the data and 
formats it into an XML output. As discussed below in more detail, the output of 

30 each operation of the extract program is in a nested conditional relation format. 
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Figures 4-9 are flow diagrams illustrating processing of the compiler of the 
data integration engine in one embodiment. Figure 4 is a block diagram 
illustrating a function to generate an execution program. The function first 
generates the extract program and then generates the construct program. In block 

5 401, the function invokes a generate extract program function to generate an 
extract program for the specified query against the specified data stores. In block 
402, the function invokes the generate construct program function to generate a 
construct program to generate the results from the extracted data. 

Figure 5 is a flow diagram illustrating processing of the generate extract 

10 program function in one embodiment. In block 501, the function generates an 
extract plan. In block 502, the function identifies fragments of the extract plan. A 
fragment of an extract plan are the set of operations that are applied to data 
derived from a single data source. Operations that apply to data from multiple 
data sources are grouped into one fragment. In block 503, the function optimizes 

15 the operations of the fragments and then returns. 

Figure 6 is a flow diagram illustrating the processing of the generate extract 
plan function in one embodiment. In block 601, the function receives the XML 
query. In block 602, the function generates a match expression for the logical 
match associated with the data store. In block 603, the function creates the Joinln 

20 graph from the match expression using the mapping for the data store. In block 
604, the function generates the native query from the Joinln graph. The function 
indicates additional processing to generate the extract plan from the Joinln graph. 
Blocks 602-604 illustrate the generation of the native query for the sorted outer 
union of the leaf nodes of the extract plan. The ellipses indicate other processing 

25 performed by the function. The function then returns. 

Figure 7 is a flow diagram illustrating processing of the match expression 
function in one embodiment. This function is passed an XML node representing 
the data store and returns the match expression. This function is recursively 
invoked for each child node of the passed XML node. In block 701, the function 
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initializes the sub-tree to the XML node. In block 702-705, the function loops 
creating a match expression for each child node. In a block 702, the function 
selects the next child node of the XML node. In decision block 703, if all the 
child nodes have already been selected, then the function returns, else the function 
continues at block 704. In block 704, the function recursively invokes the create 
match expression function passing the child node and receiving a child sub-tree in 
return. In block 705, the function adds the child sub-tree to the sub-tree and then 
loops to block 702 to select the next child. 

Figure 8 is a flow diagram illustrating the processing of the create Joinln 
graph function in one embodiment. In block 801, the function invokes the 
generate Joinln graph passing the match expression and receiving the Joinln graph 
Q in return. In block 802, the function merges nodes of the Joinln graph. In block 
^3 803, the function processes merging of adjoining nodes of the Joinln graph and 
H then returns. 

% 15 Figure 9 is a flow diagram illustrating processing of the generate Joinln 

01 graph function into one embodiment. This function is passed a match expression 
O and returns a Joinln graph. The function is recursively invoked for each child 
O node of the passed match expression. In block 901, the function sets the Joinln 
O graph to a node corresponding to the root of the match expression. The function 
? " 20 retrieves the mapping rows that can further the path from the root. In block 902, 
the function selects the next child node of the match expression. In decision block 
903, if all the children have already been selected, the function returns, else the 
function continues at block 904. In block 904, the function recursively invokes 
the generate Joinln graph function passing the selected child node of the match 
25 expression and receiving a child Joinln graph in return. In block 905, the function 
adds the child Joinln graph to the Joinln graph and then loops to block 902 to 
select the next match expression. 

Figures 10-15 illustrate the generation of an SQL query for a sorted outer 
union node of an extract program. Figure 10 illustrates the tables of the data store. 
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The arrows between the tables illustrate joins between tables. For example, arrow 
1001 represents a join between the third column of table 1.1 and the first column 
of table 2. 1. Figure 1 1 illustrates the results of the sorted outer union for the tables 
of Figure 10. Figure 12 illustrates the SQL query for each of the tables of Figure 

5 10 that are used to generate the sorted outer union. 

Figure 13 is a flow diagram illustrating the processing of a function to 
generate a sorted outer union. In block 1301, the function selects the next table of 
the source data store. In decision block 1302, if all the tables have already been 
selected, the function continues at block 1304, else the function continues at block 

10 1303. In block 1303, the function invokes the generate SQL query for the selected 
table and then loops to block 1301 to select the next table. In block 1304, the 
function executes the generate SQL queries against the tables. In block 1305, the 
function aggregates of the result of the queries into a table. In block 1306, the 
function sorts the results and then returns. 

15 Figure 14 is a flow diagram illustrating processing of a generate SQL query 

function in one embodiment. In block 1401, the function outputs a select, from, 
and where clause for the query. In blocks 1402-1408, the function loops selecting 
each table in a join path of the data store. In block 1402, the function selects the 
next table in the path. In decision block 1403, if all the tables have already been 

20 selected, then the function returns, else the function continues at block 1404. In 
block 1404, the function adds the table to the from clause. In block 1405, the 
function adds the table to the where clause. In block 1406-1408, the function 
loops selecting each column of the selected table. In block 1406, the function 
selects the next column. In decision block 1407, if all the columns have already 

25 been selected, then the function loops to block 1402 to select the next table of the 
path, else the function updates the select clause with the column and then loops to 
block 1406 to select the next column. Columns of tables not in the selected path 
are set to null. 
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Figure 15 is a block diagram illustrating an extract program. Each of the 
leaf nodes 1501-1505 represent SQL queries that are applied to a data source. 
Node 1506 represents a nesting of the results of nodes 1501 and 1502. Node 1507 
represents a nesting of the results of nodes 1506 and 1503. Node 1508 represents 
5 a selection on the results of node 1507. Node 1509 represents a nesting of the 
results of nodes 1504 and 1505. Node 1510 represents a join of the results of 
nodes 1508 and 1509. Node 1511 represents a projection of the results of node 
1510. Node 1512 represents the construct program that accesses the extract 
program. 

10 Figure 16 is a flow diagram that illustrates code of a join node of an extract 

program in one embodiment. In one embodiment, the processing of each node of 
extract program is performed a pipeline manner, that is each node returns only the 
data needed to satisfy the next request from the construct program. In decision 
block 1601, if the right node is a fully processed, then the function continues at 

15 block 1602, else the function continues at block 1605. In decision block 1602, if 
the left node of the join is fully processed, then the function returns, else the 
function continues at block 1603. In block 1603, the function retrieves at the next 
results from the left node. In block 1604, the function initializes the right node 
based on the results returned from the left node. In block 1605, the function 

20 retrieves the next results from the right node. In decision block 1606, if the results 
returned from the right node are contained in nested table, then the function 
returns an iterator for that table, else the function returns the results. The iterator 
for a table is an optimization that allows nodes higher in the extract program to 
retrieve subsequent rows of the nested table without having to invoke lower-level 

25 nodes in the extract program. 

Figure 17 illustrates the output of the nodes of the extraction plan to Figure 
15. When the construct program 1712 invokes root node 1711 of the extract 
program, that invocation is propagated down to the leaf nodes. The SQL query of 
node 1701 returns result 1713, and the SQL query of node 1702 returns result 



[33729-8001 /SL01 2050.406] 



-17- 



8/1/01 




1714. Node 1706 indicates to nest results of nodes 1701 and 1702. In this case, 
result 1714 is nested within result 1713 as indicated by result 1715. Node 1703 
returns result 1716. Node 1707 nests result 1716 within result 1715. The 
subscript within node 1707 specifies a target for the nesting. In this case, the 

5 subscript 2 indicates to nest within the third column of result 1715. (Columns are 
identified starting with column 0.) Result 1717 represents the result of the nesting. 
Node 1708 represents selection on the result 1717. The target represented by 
subscript 2.1 indicates to select the third column and the first row within the third 
column. The result of the selection is result 1718. Results 1719-1723 illustrates 

10 the results of the other nodes of the extract program. 

LMatch Operation 

The LMatch operator performs navigation-based selection over XML 
input. The following example illustrates an XMLQL syntax fragment and the 
LMatch instance that is created to model it inside the compiler: 

15 

<axb><c>$c</></></> ELEMENT_AS $a 

LMatch ($results, 11 self (a, $a) -child (b, — ) -child (c, $c) 11 ) 

20 The "se//[a,$a) — child(b,~) — child(c,$c)" is a match expression. In this 

example, the match expression is a tree with three nodes. The general structure of 
the XMLQL pattern is translated into an isomorphic pattern within the match 
expression. The XMLQL variables become "bindings" within the navigations. 
The LMatch operator is one of the logical operators of the internal language of the 

25 data integration engine. The LMatch operator is generally the "first" operator that 
is applied to input data and is responsible for converting XML input in to NCRs 
that are then further processed by the query engine. The LMatch operator is a 
logical operator only in that one of the actions of the Compiler is to convert 
LMatch operators into a data source-dependent form (e.g., SQL for relational 

30 databases, or QLL for QL-Lite data sources). 
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The LMatch operator defines a match against XML data. The pattern is 
defined by the "match expression," which is a tree of navigation steps. Each 
navigation step describes a "movement" from a source element or attribute to a 
target element or attribute. The parameters of the navigation step that govern 
5 navigation are as following: 

• The type of movement or navigation (child, parent, descendant etc.) The 
navigation types are based on XPath axes. 

• The name of the target element or attribute, which may be a wild card. 

• Whether the target should be an element, an attribute, or either. 
10 • Whether the navigation is optional or not. 

LMatch matching is top-down on the tree of navigation steps. That is, the 
match begins at the root of both the XML document and the root of the match 
expression. Matches for the first navigation step are sought in the entire XML 

15 document. If the first navigation is a root navigation, then it matches the root of 
the XML document (where we interpret root to be the root element, not the 
document item, as defined in DOM). If the first navigation step is something other 
than root, it is as a navigation from the root. 

Once a node or set of nodes have been identified for the first navigation, the 

20 algorithm proceeds recursively: given a matched node, attempt each of the child 
navigations from the navigation tree (where child here means "child in the 
navigation tree," rather than child type node). Each attempted navigation will 
itself yield a new set of zero or more matches, which are then continued in the 
next level of the recursion, and so forth. While the recursion proceeds down the 

25 navigation tree, the navigations do not necessarily proceed "down" the XML tree; 
navigation types can move in arbitrary directions within the XML document (e.g., 
ancestor or preceding sibling). 

If an attempted navigation yields zero matches from some source node, 
then that navigation is said to have failed. If the navigation was not marked as 

30 optional=true, then the failure of the naviagation causes the source node to be 
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"unmatched." The following match expression illustrates the failure of a 
navigation; 

seIfta,$BL)—child(b,$b)— child(c,$c) 

5 The first navigation step may yield a single element <a>. The second step 

may yield a set of <b> elements, some of which contain <c> elements and some of 
which do not. When the final navigation is evaluated, it will, for some <b> 
elements, yield no results. If the navigation is optional (optional = true), then all 
the <b> elements are included in the result. If, however, the navigation is required 

10 (optional =false\ then those <b> elements that contain no <c> elements are 
removed from the set of matches for childQo) from the root <a> element. The 
result contains only <b> elements that actually contain <c> elements. If no <b> 
elements remain after this process, then the failure propagates upward, 
"unmatching" the <a> elements (unless the child(b) navigation was optional). 

15 The evaluation of an LMatch operator is a three stage process: first, match 

the pattern within the LMatch operator against some source of XML; second, 
connect columns in the LMatch pattern with their associated items in the 
information set of the XML source; and thirs, structure those connected columns 
(the extracted information) into an NCR as indicated by the nesting settings on 

20 individual navigations. That is, an LMatch operator specifies a structural pattern 
that is sought after in a document, specifies which parts of that pattern should be 
returned, and specifies how the returned parts should be organized. The output of 
an LMatch operator is an NCR that contains the returned parts, organized as 
specified. 

25 The parameters of the LMatch that govern how results are constructed are 

these: 

• The set of columns returned. An NCR column "names" some piece of 
information returned from an element or attribute node that has been 
matched. There are several kinds of columns: 
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o value: the contents of a simple element or attribute 

o subtree: the entire element (not applicable to attributes) 

o name: the name of the element or attribute 

o text: the text value of an element (used to extract text from mixed- 

5 content elements; in a simple element it is equivalent to 'value') 

o table: the table column gives a name to the entire set of results when 

nested=true 

• Whether or not the results of the navigation should be nested. 

Each navigation step may have one or more of the column types present. 
10 The type of the column is derived from the type of the corresponding contents of 
the XML document (except for the table column). 

These columns are structured into an NCR based on the nested flag and the table 

column: If nested=true, then the table column was specified, and the navigation 

creates a nested NCR. This NCR contains all the other columns for this 

15 navigation step, as well as all the columns generated by the subtree of navigations 

beneath it. For example: 

self{di--)— N cM4b,$b,$btable)— child(c,$c) 
— cMJ(d,$d) 

20 The root (top-level) navigation may also be nested or unnested. In addition, 

the LMatch operator, like other operators, provides an additional column that 
names the its entire schema. The childQoi) navigation is a nested navigation that 
results in a nested NCR, named Sbtable, in the result. This NCR will contain 
columns $b (because $b is a column on the child(b) navigation) and $c (because 

25 $c is a column on a navigation in c/z/W(b)'s subtree). Figure 18 illustrates a final 
NCR structure. 

A depth-first traversal of the match expression of an LMatch operator is 
used to construct the columns of the output NCR. As a result, the LMatch 
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operator also defines an ordering of the columns as well as their structure and 
names. 

When a navigation matches multiple times, then the results differ based on 
whether the navigation is nested. If the navigation is a nested navigation, then a 

5 nested NCR is created, which will contain the matches. But if the navigation is 
not nested, then the results are combined via a cross-product with all the other 
columns in the same table. So, if one <b> element contained multiple <c> 
elements, the Sbtable would contain the corresponding <b>-<c> pairs. 
Navigations that are not nested can be treated as a special case of nested 

10 navigations. Thus, an LMatch operator can be evaluated as if all navigations are 
nested. Then, for each navigation that is actually nested, a an LFlatten operation 
can be used to remove the table corresponding to the nesting. 

A subtree column results in the entire XML subtree, tags and all, being 
returned as an atomic value. (This corresponds to the ELEMENT AS notation in 

15 XML-QL.) The compiler transforms this column into a more complex LMatch 
expression that "pulls apart" the entire subtree contents and modifies the rest of the 
execution unit to reconstruct the result back into a subtree when needed. As a 
result, subtree columns exist initially, but they are replaced with more complex 
patterns. Before they are rewritten, the subtree columns are modeled in the NCR 

20 schema as a single, static column. After the rewrite, they begin with a table- 
valued column containing the nested results. 

Advantages of the LMatch operator being a single, complex operation 
include: 

1. When queries are generated for query languages which themselves contain 
25 some form of matching operations, then mapping onto those operations is 

enabled. 

2. Certain optimizations that may be done on navigational matching are better 
enabled by capturing succinctly the navigation that is being done. In 
particular, reasoning about substitution of a descendant relation with a 
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union of paths, and vice versa. Also, also reasoning about document order 
relations. 

3. The LMatch operator combines two kinds of capabilities into a single 
operator: navigational operations and composition of the results into a 
5 complex structure (the NCR). This allows a concise representation of a 

very common idiom. 

The LMatch operator can be matched against a tree that represents an XML 
generator, rather than the actual XML document. For example, 

• The XML RDB Map can be interpreted as a generator of an XML 

10 document from a relational database. Matching the LMatch operator 

against an XML RDB Map is a fundamental step in converting the XML 
query into SQL. 

• The Construct Program of a query can be interpreted as a generator of an 
XML document from an NCR. Matching the LMatch operator against a 

15 Construct Program is a fundamental step in composing views. 

The algorithm for matching against tree-structured XML generators is very 
similar to the algorithm for matching against XML input directly. One difference 
is that where matching against an XML document generates tuples of output, 
matching against a generator generally produces a Correspondence Tree, which 

20 encodes all the potential correspondence points between the nodes of the generator 

and the navigation steps of the LMatch. 

An XML generator is a tree (actually, a forest suffices) where the nodes in 

the tree represent the generation of XML elements or attributes or their values, and 

arcs between nodes represent inclusion. For example: 

25 element("person") — attribute("ssn") — value() 

— element("name") — value() 
— element( ,! address") — value() 

The XML generator also indicates the arity of each arc. The values for 
30 arity are optional (0 or 1), singular (exactly one) and multiple (0 or more). If an 
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arc is marked multiple, then the generator can generate more than one instance of 
the child node for each parent instance. In the above example, if the arc between 
"person" and "name" were marked multiple, then a person could have zero or 
more names. The arity of an arc is indicated by a subscript on the arc as shown in 
5 the following: 

element("person") — s attribute("ssn") — value() 

— M element("name") — value() 

— 0 element("address") — value() 
When no arity is indicated, singular is assumed. If it is not possible to 

10 derive arity information from the generator, then multiple is assumed, since it is 
the most general case. 

The Correspondence Tree tracks which navigation steps in the LMatch 
operator correspond with which nodes in the XML generator. The 
Correspondence Tree would be isomorphic to the LMatch navigation graph except 
15 for one thing: any given navigation step might match against multiple nodes in the 
generator. The following is an example of an XML generator, an LMatch 
operator, and the corresponding Correspondence Tree: 
The XML generator: 

elementCperson")! — attribute("ssn") 2 — value() 3 
20 — element("name") 4 — value() 5 

— element("name") 6 — value() 7 

The LMatch: 

se///(person)i — child(ssn) 2 
25 — c/2//c/(name)3 

Figure 19 illustrates the Correspondence Tree. 

The subscripts on nodes in the generator and LMatch distinguish otherwise 
identical nodes when they appear in the Correspondence Tree. The 
30 Correspondence Tree is "read" as: "The root navigation has a single match, 
namely the elementC'person")! node of the XML generator. From this generator 
node, the next LMatch navigation, c/z/W(name) 3? is matched against two different 
generator nodes, and so on. 
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The Correspondence Tree is a bipartite graph. A bipartite graph is one in 
which nodes come in two different alternating types. In this case, the node types 
are called navigation nodes (which reference navigation steps, and are pictorially 
indicated with brachets [ ]) and choice nodes (which reference generator nodes, 

5 and are pictorially indicated with braces { } ). A bipartite graph is interpreted as 
having two different kinds of arcs, which are indicated by lines of different 
weights: light lines are choice arcs (arcs from navigation to choice nodes, 
choosing amongst multiple correspondences) and heavy lines are navigation arcs 
(arcs from choice to navigation nodes, following the navigation relationships in 

10 the LMatch operator). 

A correspondence is a (navigation step, generator node) pair of a 
correpondence tree. A correspondence is derived from a choice node by including 
the navigation step from the parent. For example, the following subgraph of a 
correspondence tree yields the following correspondence: 

15 subtree: [ c/2//tf(name) 3 ] — { S: element("name")4 } 

correspondence: { c/zz'/<i(name)3, element("name")4 } 

The following matching algorithm generates the Correspondence Tree, 
given an LMatch operator and an XML generator as input. The algorithm is a top- 
20 down recursion over the LMatch navigation graph. 

The XML generator has the following operations: 



XMLGenerator.rootO -> ordered list of Genera to rNode 
GeneratorNode.typeO -» { "element" | "attribute" | "value" } 
Gene rato rNode . name ( ) GName 

GeneratorNode.genChildrenO -> list of GeneratorNode 

Gene rato rNode . arity ( childNode) -» { "S" I "M" I "O" } 



In this example, the LMatch operator is limited to the following navigation 
25 types: root, child, self. The nested flag on LMatch navigation steps is irrelevant to 
matching. The LMatch operator provides the following pseudo code for accessing 
the match expression: 
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LMatch. root { ) -> NavStep 

NavStep. type ( ) -» { "root" | "child" | "self" } 
NavStep. ea ( ) { "element" | "attribute" | "either" } 
NavStep . name ( } NName 

NavStep . navChildren ( ) -> list of NavStep 

NavStep . optional ( ) boolean 

There is also a function, nameMatch(GName, NName) -> boolean, that 

returns true or false as the name from a generator node matches the name of an 
5 LMatch navigation. The Correspondence Tree provides the following operations: 



CorrespondenceTree . root ( ) ~$ NavigationNode 
CorrespondenceTree . createRoot ( NavStep ) 

NavigationNode . new ( NavStep ) 
NavigationNode . navStep ( ) -> NavStep 

// Model . navStep () . type () 
NavigationNode.typeO -> { "root" | "child" | "self" } 

// And . navStep () . name () 
NavigationNode . name ( ) NName 

NavigationNode . choiceChildren ( ) list of ChoiceNode 

NavigationNode . addChoiceChild ( ChoiceNode ) 

ChoiceNode . new { GeneratorNode, arity ) 
ChoiceNode . generatorNode ( ) -> GeneratorNode 

ChoiceNode. type () -> { "element" | "attribute" | "value" } 
ChoiceNode . name ( ) -> GName // ditto 

ChoiceNode. arity () -> { "S" I "M" t "0" } 
ChoiceNode . navChildren ( ) list of NavigationNode 

ChoiceNode . addNavChild ( NavigationNode ) 



The following illustrates the BuildCorrespondence function that is invoked 
to build a Correspondence Tree for an XML generator and an LMatch operator: 

10 

// Assume a rooted LMatch match expression / 

// normalize the LMatch to make this true if necessary . 

BuildCorrespondence ( XMLGenerator g, LMatch lm ) 

{ 

// create the correspondence tree 
ct <- new CorrespondenceTree 
nn <- new NavigationNode ( lm.root() ) 
// bootstrap the first level of expansion f 
// matching root against roots 



// ditto 
// ditto 
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ct.addRoot( nn ) 

foreach{ gn in g.getRootO ) { 

cn <- new ChoiceNode ( gn, "M" 
if ( addNavs ( nn, cn } ) 

nn->addChoiceChild ( cn ) 

} 

return ct 



The form of the algorithm is mutual recursion between two functions, each 
of which extends the graph by one level, or fails to do so (because there is no 
match). The subroutines return boolean values indicating whether or not they 
were successful; this value is then used to determine whether or not to continue 
and whether or not to actually add nodes to the graph. The following is the pseudo 
code for the addNavs function: 



// From a given corresponding navigation and choice node pair r 
// extend the choice node for each child navigation of the 
// navstep . 

boolean addNavs ( NavNode nn, ChoiceNode cn ) 
{ 

foreach( step in nn . navStep ( } . navChildren ( ) ) { 
stepnavnode <- new NavigationNode ( step ) 
success <- addChoices ( cn, stepnavnode ) 

// if a navigation is optional, we include the navNode, 

// even if it failed (the navNode will have no choice children) 

if ( success | | step . optional { ) ) 

cn->addNavChild ( stepnavnode ) 
else // failure of a required navigation; abort 

return false 

} 

// if no required navigation failed, return true 
return true 



10 



The following is the pseudo code for the addChoices function: 



// Given a location in the generator and a requested 

// navigation, "follow" the navigation in the generator tree, 

// finding a new layer of correspondences , 

boolean addChoices { ChoiceNode cn, NavNode nn } 

{ 

success <- false 

foreach{ gn in follow { cn . generatorNode ( ) , nn.navStepO ) { 

choicenode <- new ChoiceNode ( gn, cn . generatorNode (). arity (gn) ) 
thissuccess <- addNavs { nn, choicenode ) 
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if ( thissuccess ) { 

nn->addChoiceChild{ choicenode ) 
success <- true 

} 

} 

// return true if at least one choice worked out 
return success; 



The following is the pseudo code for the follow function: 



// Implement the actual navigation; this would be extended 
// with more types of navigation as the LMatch is extended 
// (and would probably require the generator to support more 
//powerful navigations as well r at least parent () ) . 
List<GeneratorNode> follow ( GeneratorNode gn, NavStep nav ) 

{ 

List<GeneratorNode> result <- {); 
switch ( nav. type () ) { 
case "self" : 

if ( nameMatch( gn.name{), nav . name ( ) ) 
result. add ( gn ) 
case "child" : 

foreach ( gnkid in gn . genChildren ( ) ) 

if ( (nav.eaO == "element" It nav.eaO = "either") 
&& gnkid. type () == "element" 
& & nameMatch ( gn . name ( ) , nav . name ( ) ) ) 
result. add ( gn ) 
else if ( (nav.eaO == "attribute" | 1 nav.eaO == "either") 
&& gnkid. type () == "attribute" 
& & nameMatch ( gn . name ( ) , nav . name ( ) ) ) 
result. add { gn ) 
case "root" : 

foreach ( r in xml Genera tor . root ( ) ) // [1] 
if ( namematch ( r.nameO, nav. name () ) 
result. add ( r ) 

} 

return result 

} ___ 



The BuildCorrespondence algorithm presented above does not match 
against actual XML data. However, an XML document may be considered a 
degenerate XML generators with singular-arity arcs and constant value nodes and 
and NCR is built rather than a Correspondence Tree . The relationship between a 
Correspondence Tree and an NCR is as follows: 
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• The values for any particular navigation are the concatenation of the values 
for each choice below that navigation; the result is a list of data. 

• For nested navigations, the rows of the nested table are that list of data. 

• For an unnested navigation that is at most singular, then the list of data can 

5 contain only 0 or 1 rows. In this case, the NCR column is essentially a field 

that is filled in the by value. 

• In general for unnested navigations, the list of data is "joined against" the 
existing rows of the containing table. If the navigation is optional, the join 
is an outer join, if required, an inner join. If the list has multiple entries, the 

10 effect is a cross product against the other contents of the table. 

Because navigations can result in failure that propagates recursively 

upwards, matches to the leaves are evaluated before committing to any results. 

Alternatively, the LMatch operation could contain only optional navigations or 

only required navigations in cases where the data will be present. Similarly, it is 
15 possible to eliminate the need to handle joins or cross products by limiting the 

LMatch operator to only allow unnested navigations when the data is at most 

singular. 

Two type of normalization that can be performed on LMatch operators are 
removal of (non-root) self navigations and removal of implicit cross-products. 

20 The normalized LMatch operator would consist only of a single root self 
navigation and following child navigations, where for each child navigation, 
nested=true. Alternatively, the normalization could cover either (nested-true) or 
(nested-false and optional-false and the child is known to exist in a strict 1:1 
relationship with the parent). Additional normalizations, such as requiring 

25 optional-true on all nested child steps, may also possible. 

To normalize the LMatch operator, additional operators are inserted to the 
Logical Extract Program to compensate for the changes to the LMatch operator. 
These logical operators include the LSelect, LFlatten, and LBox operators. The 
LSelect operator removes tuples from a table based on some condition. The 
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LFlatten operator flattens a nested table within an NCR. The operator is applied to 
a single nested table, and the process of flattening removes that table. The 
LFlatten operator has a boolean parameter "outer" indicating whether the 
flattening operation should behave like an inner or left outer join — that is, if the 
5 nested table is empty, does flattening remove the containing row or not. The 
LBox operator serves to introduce an artificial level of nesting within a table. 

A singular relationship between a child navigation and its parent navigation 
is identified by examining the XML schema of the data that the LMatch operates 
against. Initially, the matching algorithm has been run. After that, it can be 
10 determined, for each navigation step, which place(s) in the schema the LMatch 
operator could match. From that information, and from the cardinality 
information available in the schema, it can be identified whether the singular 
condition holds. 

The first version of the algorithm generates an LMatch that contains a 
15 single, top-level self navigation and otherwise contains only child navigations. All 
navigations (including the self at the top) have nested-true. The resulting 
navigations may have optional-true or optional-false. The implementation can 
be styled in a bottom-up or top-down traversal, but note that in either case 
compensating operators are to be inserted at both the bottom and top of the chain. 
20 The table below illustrates the various cases that can arise. The right-hand 

column has examples of the transformations. Here is a sample XML document 
this can be tested against: 



<a>al<b>bl</b> 

<c>cl<d>dl</dx/c></a> 

<a>a2<b>bl</bxb>b2</b> 
<c>cl<d>dl</dx/c> 
<c>c2<d>d2</dx/cx/a> 

<a>a3 

<c>cl<d>dl</dx/c> 

<Oc2<d>d2</d><d>d3</d></c></a> 
<a>a4<b>bl</bx/a> 
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Figures 20-25 illustrate normalization. 



If the step is the root self step of the navigation tree, and has 
nested=false, treat it the same way as a child step with nested=false 
(see below). 


Figure 20 


If the step is a child step with nested=true, do nothing. 




If the step is a child step with nested^ false, set nested-true, 
autogenerate a table column for the new nested table, and add an 
LFlatten operator to compensate. The LFlatten target is set to the 
nested table that this step generates. 

If the child step has optional =true, the LFlatten must be an "outer" 
LFlatten. 


Figure 20 
Figure 21 


If the step is a self step with optional -false, and nested=false y 
remove the step, migrating the children of the self step to the parent. 
If the self step had columns on anything, add those columns to the 
parent step. If one of the migrated columns is a duplicate of an 
existing column of the parent step, use renaming to remove one of 
the columns from the entire LEP. 


Figure 22 


If the step is a self step with optional^true and nested=true, remove 
the step, migrating the children of the self step to the parent. 
If the self step had columns on anything other than its table column, 
add those columns to the parent step, unless it would clash with an 
existing column on the parent step. In that case, add an LDup 
operator to make a new copy of the self step* s column. 
Determine the total set of columns that 'belong to' the self step 
(including the result of the LDup, if any), and insert an LBox 
operator to nest those columns, giving the result the original table 
name from the omitted self The LBox operator is inserted after the 
LDup, if there is one, but before all other steps. 


Fig 23 


If the step is a self step with optional =false and nested=true, 
proceed as in the case above. Then add an LSlelect operator to test 
for emptiness of nested table created by the LBox. Unlike other 
operator additions, this LSelect operator must be added to the end of 
the chain of operators that have been added, so that it operates only 
after any flattenings have been done at deeper levels of nesting. 


Fig 24 


If the step is a self step with optional=true and nested=false, 
proceed as in the case above, except instead of an LSelect step at the 
end, insert an LFlatten with outer =true. 





In one embodiment, the following optimization may be applied. If an LBox 
is followed by the flattening of all its columns, the nested tables can be joined with 
5 a sequence of LJoin operators (as cross products) instead. This optimization could 
be performed either during this algorithm, or as a post-processing step. To 
illustrate, the last example above could be rewritten as shown in Figure 25: 

Alternatively, the normalization can be modified to state that only 
nested-true are added to child steps that can have multiple (or, possibly, optional) 
10 values. This normalization is may be easier for inputs to create NCR' in which 1:1 
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elements are listed as flat columns of a row; any nesting on these columns may 
need to be added by an explicit LBox operator. In the case of a child step that has 
nested=false, and the step has been marked as singular without changing the value 
of the nested flag and without adding an LFlatten operation. The other steps do 

5 not change; in particular elision of a self step in the general case may result in 
adding an LBox, possibly followed by a LSelect or LFlatten operation. However, 
if all child navigations of a self navigation are singular, then the LBox and 
corresponding LFlatten can be omitted. The corresponding LSelect needs to be 
changed to a test on the NULL-ness of the columns, rather than a test on the 

10 emptiness of a nested table. This condition can be detected in a post-processing 
step, but it would require information from both the LMatch (the singularity of 
steps) and correlated information from the logical extraction program (the 
presence of LBox and LFlatten/LSelect); thus, this optimization may be 
implemented as an integral part of the recursive algorithm. 

15 Nested Conditional Relations (NCIV> Model an d Algebra 

NCR extends relational algebra in two ways. First, it makes relations heterogeneous (i.e., 
allows them to contain records of different types). Each record is accompanied by a tag, 
describing its type, hence the term conditional relation. Second, relations can be nested. 
20 The value of an attribute can be either atomic (e.g. , int, float, string) or another NCR. 

1.1 Relational Algebra 

Traditional relational data models have tables that are homogeneous and flat and selection and 
projection operators select a subset of rows and fields in a table. A homogenous table is one 
25 that has rows of the same type. A flat table has atomic fields, that is fields in the first normal 
form. The following table is a traditional relational data model. 
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Depts 



Name 


ID 


Phone 


Floor 


Payroll 


p 

r 


2345 


3 


Payroll-Temps 


P2 


2244 


1 


Payroll-NJ 


P3 


2345 


4 


Engineering 


E 


7654 


6 


ReEngineering 


E2 


2244 


3 


Marketing-US 


MU 


1818 


4 


Marketing-Europe 


ME 


9876 


2 



Each row in the table is a record of the same type; 

[Name : string, ID : string, Phone : int, Floor : int] 
5 Each field in the row is an atomic type. The table is a set of such rows. Its type is: 
Depts: {[Name : string, ID : string, Phone : int, Floor : int]} 
The following selection operation (a): 

O Fioor>3 (DeptS) 

10 

results in a subset of the original table, consisting of the highlighted rows below: 



Name 


ID 


Phone 


Floor 


Payroll 


P 


2345 


3 


Payroll-Temps 


P2 


2244 


1 


Payroll-NJ 


P3 


2345 


4 


Engineering 


E 


7654 


6 


ReEngineering 


E2 


2244 


3 


Marketing-US 


MU 


1818 


4 


Marketing-Europe 


ME 


9876 


2 



The following projection operation (IT): 

15 IT Name, Phone (p Floor>3 (Depts)) 

results in a subset of the original table, consisting of the highlighted rows below: 
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Name 


ID 


Phone 


Floor 


Payroll 


P 


2345 


3 


Payroll-Temps 


P2 


2244 


1 


Payroll-NJ 


P3 


2345 


4 


Engineering 


E 


7654 


6 


ReEngineering 


E2 


2244 


3 


Marketing-US 


MU 


1818 


4 


Marketing-Europe 


ME 


9876 


2 



The Nested Conditional Relation model (NCRs) has tables that are heterogeneous and nested 
and have generalized version of selection and projection the select a subset of the fields. 



1.2 Conditional Relations 

5 A heterogeneous collection, or conditional relation is a relation which may have rows of 
different types. The Dept and Persons persons tables below are of the traditional relational 
model. 



Depts 



Name 


ID 


Phone 


Floor 


Payroll 


P 


2345 


3 


Payroll-Temps 


P2 


2244 


1 


Payroll-NJ 


P3 


2345 


4 


Engineering 


E 


7654 


6 


ReEngineering 


E2 


2244 


3 


Marketing-US 


MU 


1818 


4 


Marketing-Europe 


ME 


9876 


2 



Persons 



SSN 


Name 


Salary 


123456789 


Smith 


44444 


234567890 


John 


55555 


111111111 


Sue 


66666 



A heterogeneous table consisting of departments and persons is obtained by interleaving the 
rows of the Depts and Persons tables as shown below ; 
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DepartmentsPersons 




Mcune 


ID 


Phone 


Floor 


Dept: 


Payroll 


T> 

r 


2345 


3 




Name 


ID 


Phone 


Floor 


Dept: 


Payroll- 1 emps 


r>o 

rZ 


2244 


i 






^Name 


So/tory 


Pers: 


123456/59 


oimtn 


44444 




SSN 


Name 


Salary 




Pers: 




John 


55555 




Name 


ID 


Phone 


Floor 


Dept: 


Pavroll-NJ 


P3 


2345 


4 




Name 


ID 


Phone 


Floor 


Dept: 


Engineering 


E 


7654 


6 




SSN 


Name 


Salary 


Pers: 


111111111 


Sue 


66666 




Name 


ID 


Phone 


Floor 


Dept: 


ReEngineering 


E2 


2244 


3 




Name 


ID 


Phone 


Floor 


Dept: 


Marketing-US 


MU 


1818 


4 




Name 


ID 


Phone 


Floor 


Dept: 


Marketing- 
| Europe 


ME 


9876 


2 



The Departments rows have four fields and the Persons rows have only three fields. To 
represent such a table, a is added to each row. The value of the tag can be either Dept or 
5 Pers. Each row has a structure that depends on this tag. The type of such a row is called a 
tagged union type, and is denoted as: 

<Dept: [Name : string, ID : string, Phone : int, Floor : int] | 
Pers: [SSN : int, Name: string, Salary: int]> 
A value of this type is either a record of type [Name : string, ID : string, Phone : mt, FIoo. r : int] 
10 preceded by the tag Dept, or a record of type [SSN : int, Name: string, Salary: int] preceded by a 
tag Pers. 

The type of the entire table DepartmentsPersons is a set of a tagged union type: 

DepartmentsPersons: {<Dept: [Name : string, ID : string, Phone : int, Floor : int] | 
Pers: [SSN : int, Name: string, Salary: int]>} 

15 

The following selection operator selects rows with all departments above the 3 rd floor: 

a < D ept/(Fioor>3)> (DepartmentsPersons) 
The "Dept" tag in the condition (i.e., "Dept/(Floor>3)") indicates to select rows with a Dept 
tag. The "Floor>3" indicates to select rows that have Floor>3. All rows that do not have the 
20 Dept tag are selected intact. Thus, the type of the result is: 
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{<Dept: [Name : string, ID : string, Phone : int, Floor : int] | 
Pers: [SSN : int, Name: string, Salary: int]>} 

The result is the highlighted rows as shown below: 



Dept: 


Name 


ID 


Phone 


Floor 


x^ayron 


p 

ST 


2345 


3 




Name 


ILs 


Phone 


Floor 


Dept: 


Payroll-Temps 


P2 


2244 


l 


Pers: 


SSN 


Name 


Salary 




Smith 

iJllllUI 


44444 


Pers: 


SSN 


Name 


Salary 


234567890 


John 


55555 


Dept: 


Name 


ID 


Phone 


Floor 


Payroll-NJ 


P3 


2345 


4 


Dept: 


Name 


ID 


Phone 


Floor 


Engineering 


E 


7654 


6 


Pers: 


SSN 


Name 


Salary 


111111111 


Sue 


66666 


Dept: 


Name 


ID 


Phone 


Floor 


ReEngineering 


E2 


2244 • 


3 


Dept: 


Name 


ID 


Phone 


Floor 


Marketing-US 


MU 


1818 


4 




Name 


ID 


Phone 


Floor 


Dept: 


Marketing- 


ME 


9876 


2 


Europe 









The following selection operation selects departments above the 3 rd floor AND people earning 
more than 50000: 

g <Dept/(Fioor>3) | Pers/(Saiary>5oooo)> (DepartmentsPersons) 

The condition applies to both Dept rows and Pers rows. For Dept rows, the condition 
specifies Floor>3; for Pers rows, the condition specifies Salary>50000. The result consists 
of the highlighted rows below: 
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DepartmentsPersons 






Name 


ID 


Phone 


Floor 


Dept: 


yayron 


P 


HAS 


3 




Name 


ID 


Phone 


Floor 


Dept: 


Ppvroll-TemDS 


P2 


2244 


1 




SSN 


Name 


Salary 




Pers: 


123456789 


Smith 


44444 






Name 


Salary 


Pers: 


234567890 


John 


55555 






Name 


ID 


Phone 


Floor 


Dept: 


Payroll-NJ 


P3 


2345 


4 




Name 


ID 


Phone 


Floor 


Dept: 


Engineering 


E 


7654 


_6 






Name 




I Salary 




pp»*c • 


1-1-1-111111 

lllllllll 


Sue 




I 66666 






Name 


ID 


Phone 


Floor 


Dept: 


ReEngineering 


E2 


2244 


3 




Name 


ID 


Phone 


Floor 


Dept: 


Marketing-US 


MU 


1818 


4 




Name 


ID 


Phone 


Floor 


Dept: 


Marketing- 
Europe 


ME 


9876 


2 



The same result can be achieved by applying the two selections in sequence, that is. 

O < D ep,/(Floor>3) | Pen,/(Salar y >50000)> (DepartmentsPersons) = 

= o < D ep^(F. 0 or>3)>(a<Pe ra /(Saia 17 > 5 oooo)> (DepartmentsPersons)) 
= a<p crs /(s a .a^>5oooo)> (a< D ept/ ( no„ r >3)> (DepartmentsPersons)) 



10 



The following projection operation projects out the Name and Phone fields for the Dept rows 
and the Name field for the Pers rows: 

IT ^pUNa^Phone] , ta [Namep (O <Dep t /(F 1 o„ r >3) , Pen«> 5 0000^ (DepartmentsPersons)) 

The type of the result is : 

{<Dept: [Name : string, Phone : int] | Pers: [Name: string]>} 
The results consist of the highlighted fields below: 
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DepartmentsPersons 




equivalent to: 



10 



1 3 Nested Conditional Relations 

Project or Committee 
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Dept: 
Dept: 



Pers: 



Pers: 



Dept: 
Dept: 



Pers: 



Dept: 
Dept: 
Dept: 



DepartmentsPersons 



Name 


ID 


Phone 


Floor 


T*flvro11 


p 
i 


2345 


3 


Name 


ID 


Phone 


Floor 


Payroll-Temps 


P2 


2244 


1 


SSN 


Name 


Assignments 






Project: 


Name 


Lang 








Compiler 


C++ 






Project: 


Name 


Lang 


123456789 


olllllll 




Optimizer 


C++ 






Committee: 


Name 










Awards 








Project: 


Name 


Lang 








Wrapper 


Java 




Name 


Assignments 






Project: 


Name 


Lang 








Compil 


er 


C++ 






Project: 


Name 


Lang 








Wrapper 


C++ 


234567890 


John 


Committee: 


Name 










Awards 








Committee: 


Name 










Promotion 








Committee: 


Name 










Disciplinary 




Mime 


ID 


Phone 


Floor 


Ti„ 11 x T T 

Payroll-NJ 


P3 


2345 


4 


Name 


TPi 
11 J 


Phone 


Floor 


Engineering 




7654 


6 


SSN 


Name 


Assignments 






Project: 


Name 


Lang 








Compiler 


Java 






Project: 


Name 


Lang 


111111111 


Sue 




Optimizer 


C++ 






Committee: 


Name 










Promotions 








Project: 


Name 


Lang 








Wrapper 


Java 


Name 


ID 


Phone 


Floor 


ReEngineering 


E2 


2244 


3 


Name 


ID 


Phone 


Floor 


Marketing-US 


MU 


1818 


4 


Name 


ID 


Phone 


Floor 


Marketing-Europe 


ME 


9876 


2 



The type of this table is: 
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{<Dept: [Name : string, ID : string, Phone : int, Floor : int] | 
Pers: [SSN : int, Name: string, 

Assignments: {<Project:[Name:string, Lang: string] | 
Committee: [Name: string]>}]>} 

5 

Rows tagged with Dept are flat records. The rows tagged with Pers have an Assignments 
field with its value as another NCR, with its rows tagged either with Project or with 
Committee. In this example, there is only one level of nesting, in general, however, there 
may be arbitrary levels. 

10 The following projection operation select the Name and Phone fields of the Dept rows and 
the Name field of the Pers rows. 

n <Dept[Name J Phone],Pers[Name]> (Dep ailment sPerSOns) 

The result is a flat relation of type: 

{<Dept: [Name : string, Phone : int] 1 Pers: [Name: string]>} 

15 Projections and selections can be combined and applied to the inner relations. This is done 
with combined operator, called Combo, that does both the selection and the projection. A 
combo operator takes an argument p, called a p-former, that describes what selections and 
projections are to be done. The p-former generalizes both the argument in a selection, ct p , and 
that in a projection n p . The following is an example of a p-former: 

20 p = <Dept/(Floor>3):[Name,FIoor] | 
Pers/(Name like "S%"): 

[Name, Assignments: {<Project/(Lang="C++") [Name]| 

Committee/(Name= ,, Promotions")[Name]>}]> 

25 Then the combo operator is written as: 
Ep(DepartmentsPersons) 
This combo operator applies the selection condition (Floor > 3) and projects on the 
Name and Floor fields for the Dept rows. The combo operator also selects on the 
condition (Name like *"S% H ) then projects on Name and Assignments fields on the Pers 

30 row. Furthermore, this combo operator processes Assignments recursively as follows. 
This combo operator applies the selection condition (Lang = "C++") and projects on the 
Name on Project rows and selects on (Name = "Promotions") and projects on the Name 
field on Committee rows. The type of the result of this combo operator is: 

35 {<Dept: [Name : string, Floor : int] | 

Pers: [Name: string, Assignments: {<Project: [Name: string] | 

Committee: [Name: string]>}]>} 

The results of this combo operator is the highlighted fields below: 
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DepartmentsPersons 



Name 


ID 


Phone 


Floor 


Payroll 


P 


2345 


3 


Name 


ID 


Phone 


Floor 


Payroll-Temps 


P2 


2244 


1 


SSN 


Name 


Assignments 






Project: 


Name 


Lang 








Compiler 


C++ 






Project: 


Name 


Lang 


123456789 


Smith 




Optimizer 


C++ 






Committee: 


Name 










Awards 








Project: 


Name 


Lang 








Wrapper 


Java 


SSN 


Name 


Assignments 






Project: 


Name 


Lang 








Compiler 


C++ 






Project: 


Name 


Lang 








Wrapper 


C++ 


234567890 


John 


Committee: 


Name 










Awards 








Committee: 


Name 










Promotion 








Committee: 


Name 










Disciplinary 




Name 


ID 


Phone 


Floor 


Payroll-NJ 


P3 


2345 


4 


Name 


ID 


Phone 


Floor 


Engineering 


E 


7654 


6 




Name 


Assignments 






Project: 


Name 


Lang 








Compiler 


Java 






Project: 


Name 


Lang 


111111111 


Sue 




Optimizer 


C++ 






Committee: 


Name 










Promotions 








Project: 


Name 


Lang 








Wrapper 


Java 


Name 


ID 


Phone 


Floor 


ReEngineering 


E2 


2244 


3 


Name 


ID 


Phone 


Floor 




Marketing-US 


MU 


1818 


4 




Name 


ID' 


Phone 


Floor 


Marketing-Europe 


ME 


9876 


2 
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The Combo operator selects a submatrix via a combination of selections (on tags and 
predicates) and projections (on fields). 



2 Operands and Typing 

An NCR is strongly typed which will allow type inference and type checking. The basic 
5 manipulable types are tables and single-valued attributes. The basic types are primitives or 
sets which are defined as: 

Base or primitive types: 

b ::= integer | long integer | string | float | decimal[precision.accuracy] | ... 
Manipulable types: 

10 t : := b Member of base type 

t :;= {u} Set (table) of tuples from "union type" 

Record (i.e., row), variant, and union types are defined as: 

Record type: 

15 r ::= [ai: ti, a 2 : t 2 , a n : t n ] 

where ai , a 2 . . . a„ are distinct labels called attributes, or fields, or just labels. 

Variant type: 

v ::= tag:r 

where tag is a label, called the tag of the variant type. 

20 Union type: 

u ::== <vi | v 2 | ... | v n > 
where vi , V2 , ... , v n are variant types having distinct tags. 

In the following example, a table is defined that includes both People(name: String, ssn;int) 
25 rows and Employees(name: String, ssn:int, salary: float) rows. The record types for People 
and Employees are defined as follows: 

rpeopie ::== [name: String, ssn:int] 

rempioyees ::= [name: String, ssn:int, salary :float] 

30 The variants are defined as: 

Vpeopie : "People: [name:String, ssn:int] 

Vempioyees Employees: [name:String, ssn:int, salary:float] 

and the union type is: 

35 u peop i e Empioyee '. :=<People: [name: String,ssn:int] | 

Employees: [name: String,ssn:int,salary:float]> 



[33729-8001 /SL01 2050.406] 



-42- 



8/1/01 
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ElQ ;i-Cia 



The NCR type describing a table consisting of both people and employees is: 



tpcopie|empioyees : := {<PeopIe: [name: String, ssn:int] | 

Employees: [name: String, ssn:int, salary: float]>} 



Operators 

5 A formal algebra using these types is defined using the following general principles. 

• Each operator should support tables with heterogeneous rows (i.e., a table of 
union types). 

• A different action can be specified for an operator for each unique row type. 

• Operators focus on the common case and a generalized map operator handles 
10 complex cases. 



2.1 Project 

The Project operator returns a different subset of the attributes from each variant type. The 
project operator, denoted n p , is parameterized by a list, p, of elements of the form tag: [set of 
15 attributes]. "P" is called a projection p-former. It determines both the type of the project 
operator and its semantics (which columns are being projected out). 

Defn . projection p-former: 

Given a union type with u = <tagi: ti| ... |tag m : t n >, where ti = 

[a u :t„,a 12 :t 12 ,...,a lni :t ln J, ...,t„= [a ml : t ml ,a m2 : t^,...^^ : t nmm ], a projection p- 
20 former with input u is an expression: 



p = <tag Ii [a lln ,a. 



■ ■ ■ , a hi J , tag la [a 2l2i , a 2lja , . . . , a^] , . . . , tag lq [a qiqi , a, 



]> 



25 



where the indexes satisfy: 
1< ii <i 2 <...<i q <m, 
l<i u <i 12 <...<i 1Pi <n 




30 



The "type" of the projection p-former is: 
p : : u —» u' 

where u* is defined as follows. Let t/, j=l,. . .,m be: 
t*. = [a,. : t, ,a, : ti ,...,ai :ti ] 

H L U ll ' U 12 ll 12 ' ? U lpi ll l P1 j 




: t 



: t 



q2 



,...,a ( 
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10 



15 



t'j = tj, when j£{i l3 ...,i q } 

The output type is u* = <tagi: t'i| . . |tag m : t' n >. 
Defn. Project Operator: 

Let p, u, u' be as above, and let t={u}, t'={u'}. The projection operator is: 

n p (t) = f 

The project operator only affects tuples with tags that are mentioned in p. Tuples with 
other tags are simply copied to the output, unaffected. The following table shows the 
results of applying a project operator. The input table is an EmpsDeptsSites NCR with 
Emp, Dept, and Site tags 



Emp: 

Dept: 

Emp: 

Site: 

Emp: 

Dept: 

Emp: 

Emp: 

Dept: 

Emp: 



name 


ssn 


sal 


phone 


Bob 


123-45-6789 


83000 


123-4567 


name 


loc 


mgr 




Payroll 


HQ 


Bob 


name 


ssn 


sal 


phone 


Marilyn 


321-54-9876 


78000 


487-0128 


name 


city 




HQ 


San Jose 


name 


ssn 


sal 


phone 


Qing 


673-82-3845 


39000 


674-3834 


name 


foe 


mgr 




Quality Ctrl 


HQ 


Marilyn 


name 


ssn 


sal 


phone 


Betsy 


233-23-6352 


75000 


234-3473 


name 


ssn 


sal 


phone 


Brian 


341-69-0323 


33000 


236-5325 


name 


loc 


mgr 




Sales 


HQ 


Betsy 


name 


ssn 


sal 


phone 


Sam 


356-02-6743 


43000 


672-7832 



The following projection operator is applied to the EmpsDeptsSites table: 

n<Emp:[name] | Dept: [name,mgr] | Site: [name,city]>(EttlpsDeptsSites) 

The result is the following table: 
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Emp: 

Dept: 

Emp: 

Site: 

Emp: 

Dept: 

Emp: 

Emp: 

Dept: 

Emp: 



name 




Bob 


name 


mgr 


Payroll 


Bob 


name 




Marilyn 


name 


city 


HQ 


San Jose 


name 




Qing 


name 


mgr 


Quality Ctrl 


Marilyn 


name 




Betsy 


name 


Brian 


name 


mgr 


Sales 


Betsy 


name 




Sam 



The project operator is equivalent to n< E mp:[namc] i r>ept: [name^ngr] >(EmpsDeptsSites). The Site 
records are included in the result by default. 



5 2.2 Select 

The Select operator returns a different subset of records for each variant type. The select 
operator, denoted a p , is parameterized by a list, p, of elements of the form tag/condition. "P" 
is called a selection p-former. It determines both the type of the select operator and its 
semantics. In the following, conditions and expressions are defined. 



io Defn. Expressions: 

Given k record types n, . . rk, and a type t, an expression e of type t with 
arguments n, r^ in notation: 
e : n x . . . x rk — » t 

is defined inductively below. Expressions occur in a context, which is defined to 
15 be a sequence of record types, (n', r 2 \ . . r n '); unless specified, the context is 

empty, n=0. 

1 . Attribute: if ^ = [..., a : t, . . . ] ? then $i.a is an expression of type t. 

2. Context: if r,- = [..., a : t, ...], then $[j]. a is an expression of type t. 

3. Scalar operator: if ei, e 2 are two expressions of base types bi, b 2 
20 respectively, then ei op e 2 is an expression of type b, where op is an 

operator: 

op : bi x b 2 -> b 

op is one of (+, -,*,/), or a string operator (concat, substr), or any user- 
defined function on scalar values. 
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4, NCR expression: if e\, e 2j . . . are expressions of types ti, t 2 , . . . , then 
f(ei,e 2 ,. . .) is an expression of type t, where f is an NCR expression f: ti x 

t 2 X . . . — » t. 

When k=l, then only $1 can occur (i.e., not $2, $3, . . .) and $l.a is abbreviated 
5 with a. 

Contexts are not used in selections, but are used later in the combo operator. 

Defn. Conditions (predicates) on records: 

Given k record types n, .. ., rk, a condition with arguments ri, r^ in notation: 
10 c : ri x . . . x rk — » bool 

is defined inductively as follows: 

1. if ei, e 2 are expressions of base types bi, b 2 respectively, both with 
arguments ri, . . r^ then ei oprel e 2 is a condition with arguments n, r^ 
where oprel is <, <=, >, >= or string operations such as substr, prefix, 

15 suffix, like, etc. 

2, if e is an expression of type {<...| tag:[ai:ti,. . .,a n :t n ] |...>} and ei, en 
are expressions of types ti, . . ., t n respectively, then: 

<tag:[ai:ei, a n :e n ]>INe 
is condition. 

20 3^ if e is an expression of type {...}, then: 

exists(e) 
is a condition. 
4, true, false are conditions. 

if cl, c2 are conditions, then so are ci and c 2 , ci or c 2 , not ci. 



25 



30 



Defn. Selection p-former: 

A selection p-former is an expression: 

p= <tag M /c 1 | ... | tag lk /c k > 
and its "type" is: 

p::<tagi:ri| ... |tag n :r n > -xtag^ :t h |...|tag lk : t lk > 
where i l5 ...,i k e { l,...,n} , and c, is a condition, c } :r — » bool , for j=l,. . ,k. 



35 Defn. Selection operator: 

Let p be a selection p-former. The selection operator is: 
o P ({t}) = {t} 
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The selection condition(s) only apply to tuples with tags mentioned in p. Tuples with 
other tags are simply copied to the output, unaffected. 

When the following select operator is applied to the EmpsDeptsSites table described above 

CJ <Emp / (sal>50000) | Dept / (mgr-" Betsy") | Site / (true)> (EmpsDeptsSites) 

the result is: 



Emp: 

Emp: 

Site: 

Emp: 

Dept: 



Name 


ssn 


sal 


Phone 


Bob 


123-45-6789 


83000 


123-4567 


Name 


ssn 


sal 


Phone 


Marilyn 


321-54-9876 


78000 


487-0128 


Name 


city 




HQ 


San Jose 


Name 


ssn 


sal 


Phone 


Betsy 


233-23-6352 


75000 


234-3473 


Name 


loc 


mgr 




Sales 


HQ 


Betsy 



The same operator can be expressed as: 

O <Emp / (sal>50000) j Dept / (mgr-" Betsy") > (EmpsDeptsSites) 

The select operator operates only on the top level, in that it decides for each top level record 
whether to keep it or toss it. However, the condition c can look deep inside the current record 
(e.g., by using existential/universal quantifiers). 



2.3 Rename 

15 The rename operator (p) renames tags and/or attributes. It is a generalization of the rename 
operator in the relational algebra: 



20 



Defn. Renaming p-former: 

A renaming p-former is an expression: 
p = <tagi^tagi':[aii~>aii', an^an', . 



] | tagz-rtag^foi-^i', a 2 2^a 2 2', ... ] | ... > 



Defn. Renaming operator: 

Given a renaming p-former p, the renaming operator is: 

p P ({t})={f}. 

This operator renames tagi to tag'i, and renames the fields in the record of type tagi by 
25 changing an to an', . . . ; renames tag2 to tag2*, and so on. All tags and/or labels that are 
not mentioned are left unchanged. The output type is "isomorphic" to the input type: 
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only the variant and record labels at the top level have changed. The "identity" mapping 
ai ai can be abbreviated to a t in specifying a renaming. 

2.4 Extend 

5 The extend operator (e) adds new fields to a record, each computed by some expression from 
other fields. 

Defn. Extension p-former: 

Given union types u = <tagi:ri, . . .,tag n :r n > and u' = <tagi:ri\. . .,tag n :r n '>, an extension p- 
former of type u — > u' is an expression: 
10 p = <tagi:[cii:en, ci 2 :ei 2 , ... ] | ... | tag n :[c n i:e n i, Cn 2 :en2 ? ... ]> 

where the expressions e lj5 . . . have types e^ : T[ ty', and is a record type obtained by 
adding the fields [cu^n*, ^W,. . .] to n. 

Defn. Extension operator: 

Given an extension p-former p, the extension operator is: 

15 e p ({t})={f}. 

The meaning is that new labels en, Cn, ... are added to the corresponding records, and 
their values are computed by the exrepssions en, ei 2 , . . . The values of all the other labels 
are copied into the output unchanged. As for the other operators, not all tags need to be 
mentioned: the missing ones are copied to the output. / 



2.5 Combo 

The Combo operator (Z) combines Project, Select, Rename, and Extend, and does this to 
arbitrary nesting levels. The Combo operator is parameterized by an argument that is a deeply 
25 structured expression combining arguments of Project (fl), Select (a), Rename (p), and 

Extend (s). Such an expression is called a p-former. Unlike the other operators, combo does 
not implicitly copy "the other" tags and labels to the output, but deletes them. This allows 
both copying and deleting. (For convenience, another version of the combo operator may also 
be defined that copies by default.) 

30 The rules below define a p-former inductively. A p-former, /?, has an input type / and an 
output type and the p-former is denoted by: 

p :: t -> t r 

The p-former takes an input value of type t and returns either an output value of type t' or 
"nothing." When used in a Combo operator, E p , the type of the Combo operation is {t} — > 
35 |t'} . Consider a selection in the relational algebra, a age <2o , (age<20) is a p-former: it takes a 
record and returns either the same record (if age<20) or nothing (otherwise). 
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For each p-former, there is a context (which, recall, is a sequence of record types, (n, . . . , r n )). 
Inner p-formers have a context consisting of all record types of the surrounding records. The 
top-level p-former has an empty context. 

1. The "identity p-former": 

5 _ * / — > / for every type t 

returns its input, unchanged 

2. The "record p-former": 

10 if pi :: t h -> t' l5 p k :: t Ijt -»t f k , are p-formers, {ii, i k } c {1, 2, n} and 

d: [ai:ti,... 3 a n :t n ] -^ti", e p : [ai:ti,...,a n :t n ] -»t p " are expressions, then 
[(a M -^b,):p l9 ...X^ ->b k ):p k , Cl :e l9 ... 9 c p :e p ] ::r-> r*, where r = 
[ai:ti,...,a n :t n ] and r' = [bi:ti',..., b k :tk,ci:ti", c p :t p "]. 

The (a -> b) : p components rename an attribute a to b, and apply recursively the 
15 p-former p on the value of that attribute. The c:e components introduce a new 

attribute (c) whose value is computed by the expression e over r. If the context of 
p is (ri, . . . , r n ), then the context for each of pi, . . . , pk is (n, . . . , r n , r). 
The following condition applies to p-formers in Combo operators: 

20 ( * ) a t . . . , a h are distinct and ej, . . . , e p are scalar expressions 

(The b's and c's are also distinct, which follows implicitly from their use in the 
type [bi :ti f , . . . , bk:t k ',Ci :ti", . . . ,c p :t p "]). The restriction ensures that every complex 
value is copied to the output at most once, and new values being produced are 

25 scalar: this enables simple, pipeline computation. 

Given an input value [ai:vi, . . ., a n : v n ], the p-formers pi, . . Pk first apply to the 
values Vii, . . . , v lk respectively. If any of them returns "nothing," then the record 
p-former returns "nothing." Otherwise, let vi', . . ., v k ' be the values returned by 
the p-formers, and let wi, . . . , w p be the values returned by the expressions ei, 

30 e p : the record p-former returns the record [bi:vi*, . . bk : v n ',ci:wi,. . .,c p ,:w p ]. 

3. The "variant p-former" is parameterized by a selection condition, c: 

if c : r — > bool and p : : r — > r' 
35 then (tag/c — > tag'):p :: tag:r — > tag':r' 

The condition c is checked first. If it returns false, then the p-former returns 
"nothing." Otherwise, it returns whatever p returns, but changes the tag to tag'. 
The c may use existential/universal quantifiers on the set fields of r. 



40 



4. The "union" p-former is: 

ifpi::vu vi", p k :: v ik v k ' and {ii, i k } c {1, 2, n} 
then<pi| ... | p k > :: <vi | ... |v n > -> <vi'|... | v k '> 
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Given a value of type <vi | . . . | Vk> , union p-former checks that it is of one of the 
variant types vu,. . . ,Vik: if not, it returns "nothing," otherwise it returns whatever 
the corresponding p-former returns. Neither the variant types vi , . . . , vr nor the 
variant types vi',.. , Vk are disjoint: however identical tags in the latter 
5 correspond to identical types, i.e., <vi'|. . . | Vk'> are a correctly formed type. 

5. The "set" p-former is: 

if p :: u — > u' 

then {p} :: {u} -> {u'} 

10 

Given a set {xi, . . . , x n }, the set p-former first applies the p-former p to each 
element in the set. Let yi, . . ., yk be all values returned by p (i.e., excluding 
"nothing"), then the set p-former returns {yi, . . ., yk} 

15 Defn. Combo operator: if/? is a p-former, p :: t -> t\ then: 

Z P ({t}) = ({t'}) 

Given a set {xi, . . . , x n }, the operator first applies the p-former p to each element 
in the set. Let yi, . . ., yk be all values returned by p (i.e., excluding "nothing"). 
Then Z p returns {yi, . . . , yk} 

20 

The following p-former is defined for the EmpsDeptsSites table: 

p = <Emp/(sal>50000) ->HighEarner:[name->name:_] | 
Dept/(mgr= "Betsy") -^BetsyManages:[name^riame:_| | 
Site/(true) — >Site: [name— >name:^,city->city : J> 

25 The following combo operation is applied to the table: 
Z p (EmpsDeptsSites) 

If (a — > a) is abbreviated with a, p: with p, and tag/(true) with tag, then combo operator can 
30 then be abbreviated as: 

Z<Emp/(sal>50000)-^IIighEamer:[name] [ Dept/(mgr= "Betsy")-»BetsyManages [name] | Site:[name,city]> (EmpsDeptsSites) 

The results of this combo operator is: 
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20 



HighEarner: 
HighEarner: 
Site: 

HighEarner: 
BetsyManages: 



name 




Bob 


name 


Marilyn 


name 


City 


HQ 


San Jose 


name 




Betsy 


name 


Sales 



This example illustrates the use of contexts. The following relation (base types omitted) is 
used. 

Pers:{<a:[name, birthday, projects: {<b: [title, deadline, modules: {<c:[id,date] }]>}]>} 
Each person has a set of projects, each project has a set of modules. 

a. The combo Z p2 (Pers) returns all persons that work on a project whose deadline is on 
their birthday. Its definition needs two p-formers: 

pi - <b/($l deadline=$[l].birthday):„> 
p2 = <a/(Exists(S pl ($l.projects)):_> 

The context expression $[1] .birthday in pi, which retrieves the birthday from one level 
higher up, is used in the "context" of p2, which defines the outer context to be a record 
of type [name, birthday, project]. 

b. The combo Z p3 (Pers) deletes from every person all projects whose deadline is on the 
person's birthday: 

p3 = <a:[name:^ birthday:^ projects: {<b/($l. deadline != $[1] .birthday) :_>}]> 



c. 



25 



This illustrates the use of a $[2] context. The combo S p4 (Pers) operates as before, but in 
addition it deletes all modules whose dates are on the person's birthday: 
p4 — <a:[name:^ 

birthday:^, 

projects: {<b/($l.deadline != $[1] birthday): 
[titles 
deadline:^ 

modules: {<c/($l. date != $[2] .birthday) >} 

]> 



30 



A Projection operator is a particular case of the Combo operator. For example 

n<Emp:[name] | Dept: [name,mgr] | Site. [name,city}>(EmpsDeptsSites) is the Same as 
£<Emp:[name] I Dept: [name,mgr] | Site: [name,city]>(EmpsDeptsSites) 

A Selection operator is a particular case of the Combo operator. For example 
<^<Emp/(sai>5oooo)|Dept/(m g i-"Betsy")| site / (true)> (EmpsDeptsSites) is the same as 

£<Emp / (sal>50000) j Dept / (mgr="Betsy") | Site / (true)> (EmpsDeptsSites) 
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3. A Renaming operator is a particular case of the Combo operator. For example, 
given the renaming p-former; 

p = <Emp->Employee :[name^person 5 ssn,sal,phone— >contact]] | 
Dept->Depart: [name^teammember,loc^place,mgr] | 
5 Site^Site:[name,city]> 
the renaming operator 

pp(EmpsDeptsSites) 
is the same as 

Sp(EmpsDeptsSites). 

10 4 The most general form of a Combo operator is like a submatrix selection. There 

is no copying and no unnesting involved. 
5. Combo can be used to homogenize a collection. For example, in 

EmpsDeptsSites there are three different kinds of records, and all share a name 
attribute. The following Combo operator extracts all names and constructs a 

15 homogeneous collection: 

£<Emp->Res [name] | Dept^Res [name] 1 Sitc^Res: [ n ame]>(EmpsDeptsSites). 

The result is of type 

{ <Res : [name: string]> } 
which is a homogeneous collection. 
20 6. Combo can be used to dispatch records to different types (e.g., transforming a 

homogeneous collection into a heterogeneous one). The following Combo 
operator splits Emp's into Regular and HighPaid: 

£<Emp/(sal<100k)^Regular [name, phone] | Emp/(sal>100k)^HighPaid: [name,phone]>(Emps) 

The input has type 
25 (<EmpIoyee:[name, phone, salary]>}, 

(base types omitted) while the output has type 

{<Regular:[name] | HighPaid: [name, phone]>} 

In general conditions that are applied to a tag may overlap. For example, 

employees with sal<100k may be dispatched to some type, and those with 
30 sal>50k to another type. In this case, records that satisfy both conditions will 

contribute to both outputs. 



2.6 The Simple Combo 

35 The semantics of combo is that tags not mentioned in the p-former are dropped from the 
output. The "simple" combo has a complementary semantics: only tags/labels that are to 
be modified need be mentioned. By default, all others are copied to the output. 
Moreover, the "simple" combo only does one single action, possible at some depth in the 
NCR 

40 Defn. Simple p-former: 

A simple p-former is a p-former that includes only a single selection (i.e., for a single 
tag), a single projection, renaming of a single tag or label, or an extension with a single 
new label. Formally, it is defined like a p-former with additional syntactic restrictions 
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that ensure that only one action is performed (only a projection, a selection, a renaming, 
or an extension). The other parts of the simple p-former, that do the copying, are omitted. 
The simple p-former is illustrated by the following examples: 



• <Emp/(sal>^50000)> this simple p-former is a selection and is equivalent to 
<Emp/(sal>=50000):_ | Dept:_ | Other >, i.e., copy the other tags unchanged. 
Thus, to get the equivalent "real" p-former, the omitted tags Dept and Other need 
to be added. 

10 • <Dept:[name, projects]> this simple p-former is a projection and is equivalent to 

<Emp: | Dept. [name: , projects: J, Other: > 

• <Dept:[projects:{<urgent/(deadline>="10/10/2010 n )>}]> this is a selection on 
the inner relation projects, and is equivalent to 

<Emp:_ | Dept:[name:_, floor: , projects: {<normal:_ | 
15 urgent/(deadline>= ,, 10/10/2010"):_>}] | Other:_>. 

• Omitted tags (Emp, normal) are added and omitted labels (name, floor) are 
added too. 

• <Dept[projects:{<urgent:[name, team]>}]> this is a projection at a deeper 
level. Tags and labels are added, except where projection is done: 

20 <Emp:_ | Dept:[name:_, floor: , projects: {<normal: [name: , team: J, 

urgent: >}] | Other: > 



Defn. Simple combo: 

Given a simple p-former p, the simple combo operator is: 

25 E° p ({t})={t'}. 

The superscript 0 indicates that the combo is "simple" (i.e., all missing tags and labels in 
p have to be added). The semantics is defined as follows. Given a p-former, p::t 
t',(simple or not) define the completion of p to be c(p) : t — > t" obtained from p by 
"completing" the missing tags according to the type t (i.e., c(p) should actually be 
30 denoted c(p,t); it can be defined inductively; omitted). The semantics of the simple 
combo operator is: 

Z°p(x) = Z c(p )(x) 

35 

Example 

Given NCR EmpsDeptsSites from above, the following are simple combos: 
£°<Emp/(sai>5oooo) j> (EmpsDeptsSites) is the same as: 
X<Ejnp/( Sa i>5oooo)]-_ | De P t:_>(EmpsDeptsSites) 

40 
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S°<De P t [m g r]> (EmpsDeptsSites) is the same as: 
S<Dept [mg r] | Emp _> (EmpsDeptsSites) 

The simple combos are strictly less powerful than combos, because they do not allow 
deletion of tags from the output type. For example, consider the combo 
5 £<Dcpt:[mgr]>(EmpsDeptsSites). Its output type is {<Dept: [mgr]>}. It may be expressed 
as a sequence of simple combos: 

£°<Emp/falsc:_> (£°<Dept:[mgr]> (EmpsDeptsSites)) 

10 where the second simple combo is needed to eliminate all Emp records. But, the output 
type of this expression is {<Dept:[mgr] | Emp: [name, ssn, sal, phone]>}. A type 
checker could be modified to recognize that some conditions are (equivalent to) false and 
eliminate the corresponding tag from the output type. If so, combo operators could be 
expressed as a sequence of simple combo operators. 

15 

2.7 Match 

The match operator, Q™, generalizes the combo operator by relaxing some of its restrictions. 
The match operator is parameterized by an m-former, m, that is defined inductively like a p- 
former in Combo, with two generalizations: 

20 1 . In the record m-former: 

[(a h ->b 1 ):p li ,...,(a lk ->b k ):p k ,c 1 :e!,...,c p :e p ] :: [ai:t b . . . ? a n :t„] -> [b^',..., 

b k :t k ',ci:ti", c p :t p M ] 

the labels an, . . . , a*k are not required to be distinct, and the expressions ei, ...,ep 
are not restricted to be scalars. (That is the restriction (*) is dropped.) This allows 

25 data values to be copied. 

Example: Q<p e rs:[Name^N a mei J Phone,Name^Name2]>, copies the Name value calling it 
Namel and Name2. Such copying can be expensive, when the value being 
copied is a large sub-relation. This is unlike Combo where no copying is done. 
2. There exists an "unnest" m-former, with no corresponding p-former: 

30 ifm::u-^u' 

then unnest (m) :: {u} — > u f 

(This is different from the set p-former, {p} : {u} —> {u'}). Unnest flattens an 
inner relation. When two or more unnest m-formers are used in a record in- 
former, their result consists of a Cartesian product: again, this can be expensive. 

35 

Whenever an unnest m-former is used inside another m-former m : : t t\ the result type t* is 
not a legal type any more, but an "extended" type, t' can be converted back into a legal type 
using a mapping norm. 

40 Defn. Match operator: if m : : t — > t* is a m-former, where t is a type and t' an extended type. 
Then: 
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Q m ({t}) = {norm(t')} 
Example: 

^<T:[A:unnestO, B:unnestO]> ({^^ A: (<Ti ! [a:ti l,b:ti 2 ] | T 2 :[c:t 13, d:ti 4 ]>}, 

5 B:{<T 3 :[e:t 21 , f:t 22 ] I T 4 :[g:t 23 , h:t 24 ]>}] 

>}) = 

{<T;[ A^TVtaitn^tis] | T 2 :[c.t 13 , d:t 14 ]>, 
B:<T 3 :[e:t 2 i, f:t 22 ] | T 4 :[g:t 23 , h:t 24 ]>] 

>}) 

10 

The only change in the output type is that some braces { . . . } have been erased. The output 
type is technically illegal in the type system, because each record field needs to be either 
atomic or a set. It can be normalized by pulling out all variant types to the top level and 
flattening the records. The normalized type is defined to be the output type of Q. We call 
15 norm the normalization operation. The following example illustrates the normalization 
operation: 

norm <T:[ A:<T i: [a:tii,b:t 12 ] | T 2 :[c:t 13 , d:t M ]> B:<T 3 :[e:t 2 i, f:t 22 ] | T 4 :[g:t i3 , h:ti 4 ]>]> 

= <TT 1 T 3 :[Aa:tii,Ab:ti 2 Be:t 2U Bf:t 2 2] | 
TT 1 T 4 :[Aa:tn,Ab:ti 2 Bg:t 23) Bh:t 24 ] | 
20 TT 2 T 3 :[Ac:ti 3 ,Ad:ti 4 Be:t 21 ,Bf:t 22 ] | 

TT 2 T 4 :[Ac:ti 3 ,Ad:ti 4 Bg:t 23 ,Bh:t 24 ]> 

The norm operation constructs new tag names and new field names by concatenating existing 
names. 

25 Definition of norm. The symbol "®" is used to denote the following operation between 
record and/or union types: 

[an:tn, ai 2 :ti 2 , ai m :ti m ] ® [a 2 i:t 2 i, a 22 :t 22 , a 2n :t 2n ] = 
[an:tn, ai 2 :t J2 , . .., ai m :ti m , a 2 i:t 2 i, a 22 :t 22 , a 2n :t 2n ] 

30 r ® <tagi : n | tag 2 : r 2 1 . . . | tag n :r n > = <tagi : r ® n | tag 2 : r ® r 2 | . . . | tag n :r ® r n > 

<tagi : ri | tag 2 : r 2 1 ... | tag n :r n > ® r = <tagi : n ® r | tag 2 : r 2 ® r | ... | tag n :r n ® r> 

<tagn : rn | tag i2 : n 2 | ... | tagi m :ri m > ® <tag 2 i : r 2 \ \ tag 22 : r 22 | ... | tag 2n :r 2n > = 
35 < tagiitag 2j : rn ® r 2 j | i = 1, m, j = l,n > 

In the last line tag concatenation is used. The norm operation concatenates two record types, 
or, if the two types are unions of m and n record types respectively, then constructs a new 
union type with mn record types, by considering all pairs of concatenations. 

40 The symbol is used to denote the union of two disjoint union types: 
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<tagn : r n | tagi 2 : r n | . . . | tagi m :ri m > ® <tag 2 i : r 2 \ | tag 2 2 : r 22 | ... | tag 2n :r 2n > = 
<tagn : ru| ... | tagi m :ri m | tag 2 i : r 2 \ \ . . . | tag 2n :r 2n > 



Two functions rlabel a and ulabeltag. are defined that add or concatenate a record label a, or a 
5 tag to a type: 

rlabela(t) = [a:t] where t is an atomic type or a set type 
rlabel a ([ai:ti, a 2 :t 2 , a n :t n ]) = [aai:ti, aa 2 :t 2 , aa n :t n ] 
rlabel a (<tagi:ri | tag 2 :r 2 1 . . . | tag n :r n >) = 

<tagi:rlabel a (ri) | tag 2 :rlabel a (r 2 ) | ... | tag n :rlabel a (r n )> 
10 ulabelta g (r) = <tag:r> where r is a record type 

ulabelta g (<tagi:ri | tag 2 :r 2 1 . . . | tagn:r n >) = <tagtagi:ri | tagtag 2 :r 2 1 . . . | tagtag n :r n > 



For the definition of the function norm, the definition of types ("normal types") is extended to 
" extended types " These are precisely the types t' that can occur in m-formers, m :: t -» t'. 

15 t::=b 

t:: = {u} 

t :: = u /* this is an extended type and "illegal" under the normal definition */ 

r ::= [ai:ti, a 2 :t 2 , a„:t n ] 

u :: - <tagi : ri | tag 2 : r 2 | . . . | tag n :r n > 

20 

The norm operation is defined by: 

norm(b) = b 
25 norm({u}) = {norm(u)} 

norm([ai:ti 3 a 2 :t 2 , . . an:t n ]) = rlabel a i(norm(ti)) ® . . . ® rlabelan(norm(t n )) 
norm(<tagi:ri | tag 2 :r 2 1 . . . | tag n :r n >) = ulabelta g i(norm(r i) ) © . . . 0 ulabeltagn(norm(r n ) ) 

The operation norm(t) results in a normal type; and if t is a normal type then norm(t) = t. 



2.8 Join 

30 Join takes a tuple from each input table and tests this combination to see if it meets a predicate; 
if so, it returns a combined tuple as the result. Join allows specification of a different 
predicate and name and a different output tag for each pair wise combination of types from the 
two tables. Not all pairs must have a predicate and output tag: those that do not contribute to 
the join. 

35 An "inner" join is described in the following. 



[33729-8001 /SL01 2050.406] 



-56- 



8/1/01 




Defn . Conditional predicate on two tuples: 

The Join and Nest operations need conditions on two records: 
c : x x x r, — » bool 

Defn . Combined tuple: 

5 Join produces a combined tuple as its output. Recall the "® " operator, which 

returns a new combined tuple. 

rl ® r2 = [ah: th, al 2 :tl 2 , . . al„: tl n? a2i: t2 u . . a2 m : t2 m ] where 
rl = [ah: th, al 2 :tl 2 , al n . tlj, r2 = [a2i: t2 h . . a2 m : t2 m ] 

(There is an implicit condition here that the labels in the two records are disjoint.) 

10 Defn. j-former: 

A j -former of type: 

j :: <tagh:rh | ... | tagl n :rl n > < tag2i.r2i| . . . | tag2 m: r2 m > -> 

<tag\:rl li ®r2 h | ... |tag' p :rl Ip ®r2 jp > 
is an expression of the form: 
15 j = < tagl M ,tag2 Ji / Cl -> tag\ | . . . | tagl lp , tag2 Jp /c p -> tag' p > 

where: 

1. ii, ...,i p e {1, n}, ji 3 ... j p e {1, m) such that all pairs (ii, ji), 
0p> Jp) are distinct (hence p <n 2 ), and all tags tag*i, . . tag' p are distinct 

2. c k :rl Ik xr2 Jk ^bool, fork= 1, p. 

20 Defn. Join operator: 

Let j : : tl x t2 -> t be a j-former. Then the join operator is: 

[xiati},^})^ w 

25 



30 



2.8.1.1.1.1 Example 

The following NCRs are used to illustrate a join of two tables: 
2.8.1.1.1.1.1 Depts 



Dept: 
Dept: 
Dept. 



Dept: 



dname 


foe 


Payroll 


HQ 


dname 


toe 


Quality Ctrl 


HQ 


dname 


loc 


Sales 


HQ 


dname 


loc 


Personnel 


Satellite 
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2. 8.1.1.1,1.2 EmpSites 



Emp: 

Emp: 

Site: 

Emp: 

Emp: 

Emp: 

Emp: 



ename 


ssn 


dept 


Rob 




a d. y i 


ename 


ssn 


dept 


ivxcii 11 y 11 






sname 


city 




HQ 


San Jose 


ename 


ssn 


dept 


Qing 


673-82-3845 


Quality Ctrl 


ename 


ssn 


dept 


Betsy 


233-23-6352 


Sales 


ename 


ssn 


dept 


Brian 


341-69-0323 


Sales 


ename 


ssn 


dept 


Sam 


356-02-6743 


Payroll 



A join on the two tables can be performed with one join predicate for (Dept x Emp) and 
another for (Dept x Site): 

t^i <Emp,Dept/($l.dept=$2 dnamc)^EmpLoc | Site, Dept /($l.loc=$2 sname)^FullDept> (EltlpSiteS, Depts) 

returns the following NCR: 



EmpLoc: 
EmpLoc: 
FullDept: 
FullDept: 
FullDept: 
EmpLoc: 
EmpLoc: 
EmpLoc: 
EmpLoc: 



ename 


ssn 


dept 


dname 


loc 


Bob 


123-45-6789 


Payroll 


Payroll 


HQ 


ename 


ssn 


dept 


dname 


loc 


Marilyn 


321-54-9876 


Quality Ctrl 


Quality Ctrl 


HQ 


sname 


city 


dname 


loc 




HQ 


San Jose 


Payroll 


HQ 




sname 


city 


dname 


loc 




HQ 


San Jose 


Quality Ctrl 


HQ 




sname 


city 


dname 


loc 




HQ 


San Jose 


Sales 


HQ 




ename 


ssn 


dept 


dname 


loc 


Qing 


673-82-3845 


Quality Ctrl 


Quality Ctrl 


HQ 


ename 


ssn 


dept 


dname 


loc 


Betsy 


233-23-6352 


Sales 


Sales 


HQ 


ename 


ssn 


dept 


dname 


loc 


Brian 


341-69-0323 


Sales 


Sales 


HQ 


ename 


ssn 


dept 


dname 


loc 


Sam 


356-02-6743 


Payroll 


Payroll 


HQ 



10 



2.9 Outer Join 



An outer join has the same syntax as an inner join, with minor additional restrictions. 
The semantics differs: 
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Defn. oj-former: 

Lettl =<tagh:rli | ... | tagl„:rl n > and t2 = < tag2i r2i| . . . | tag2 m: r2 m >. An oj- 
former for type: 

oj:: tl, t2 ~~>t\ 0 t2© <tag\ : rl M ®r2 J( | ... |tag' p :rl ®r2 Jp > 
5 is an expression of the form: 

oj = < tagl h , tag2 Ji / Cl -> tag\ | . . . | tagl lp , tag2 Jp /c p -> tag' p > 

where: 

1. ii, ...,i p e {1, n}, ji, ... j p e {1, m} such that all pairs (ii, ji), 
(i p , j p ) are distinct (hence p <ran), and all tags tag'i, . . . , tag' p are distinct 
10 2. c k :rl lk xr2 jR ->bool, for k= 1, p. 

3. all tags tag'i, . . . , tag' p are distinct, and they are also distinct both from 
tagli, ...,tagl„ and from tag2i, ...,tag2 m 

Defn, Outer Join operator: 

Let oj : : tl x t2 — » t be an oj-former. The outer-join operator is: 

Example 

20 The outer join is illustrated by a data integration scenario. There are two sources of 

persons' phone numbers where each source has an attribute that tells us the confidence in 
that piece of information: 

Soiircel: {<sourcel:[namel: string, phonel:int, confl:real]>} 
25 Source2: {<source2:[name2:string, phone2:int, conf2:real]>} 

The integration is done in two steps. First, the outer join is computed, then a 
selection/project that encapsulates the logic of the integration is applied. The first step 
results in the raw data: 

rawIntegratedData = Sourcel □ IX] □ oj Source2 

35 

where the oj-former is: 

oj = <sourcel, source2/($l.namel=$2.name2) -> integrated > 

40 The type of rawIntegratedData is: 

rawIntegratedData :{<sourcel:[namel, phone I , confl] 
| source2:[name2, phone2, conf2] 

| integrated: [namel,name2,phonel,phone2,confl,conf2]>} 

45 

That is, it will include all "integrated" records, as well as "dangling tuples" from each 
source. The second step can now apply an arbitrarily sophisticated integration logic. For 
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example, source 1 may be trusted more than source 2, have some complex rules on how 
to deal with conflicting information, and drop records where the confidence is too low: 

intcgratedData = Z p (rawIntegratedData) 

5 

where the p-former p encapsulates the integration logic: 

p = <sourcel/(confl > 0.1) — > certain: [namel name, phonel — > phone] 
| source2(conf2 > 0.5) — » certain :[name2 — > name, phone2 -» phone] 
10 | integrated/(confl > 0.4) — » certain: [namel -» name, phonel — > phone] 

| integrated/(conH<0 4 and conf2>0 7) -> 

certain: [namel— >name, phone2^phone] 
| integrated/(confl in 0.1. .0.4 and conf2 in 0.5. .0.7) -» 

uncertain: [namel — » name, phonel, phone2] > 

15 

The type of integratedData is: 

integratedData: {<certain:[name, phone], uncertain: [name, phonel, phone2]>} 

20 that is, in some cases both phone numbers are kept since the confidence does not favor 
one over the other. 



2.10 Nest 

The Nest operator works like a left outer join, but it nests all matching children within the 
25 tuple of each parent. Nesting is commonly done in XML-QL subqueries, and any time there 
is a l:n parent-child hierarchy in the output. Nest has left outer join semantics, rather than 
inner join semantics, and that it preserves the order of the parent relation. Nest can rename 
both the tag types for the nested tuples and for the parent tuples. 



Defn. n-former. 

30 Given n x m predicates: 

Cij = rli x r2j — > bool 
and n new labels, bi, . . . , b n . . An n-former of type: 

n:: <tagh : rl l | . | tagl„ : rl n > <tag2i: r2i| ... | tag2 m : r2 m > -> 
<tagi:n ® [bi : {u 2 }] | ... | tag n : r n ® [b„:{u 2 }]> 
35 is given by an expression: 

n = <tagn : [bi : <tag 2 i/c,i | . . . | tag 2m /ci m >] | i = 1, . . n> 

Defn. Nest operator: 

Let n :; ui, u 2 —> u be an n-former. Then 
Nest n : ({ui}, {u 2 }) = {u} 

40 
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Example This example uses same Depts and EmpsSites relations of types: 
Depts:{<Dept:[dname, loc]>} 

EmpsSites: {<Emp: [ename, ssn, dept] | Site: [sname, city]>} 
and performs the operation: 

NeSt <Dept:[info <Emp/($l dname-$2 dept) j Site/($l.loc = $2 sname)>]>(DeptS, EmpsSites) 

The result has type: 

{<Dept: [dname, loc, info:{<Emp: [ename, ssn, dept] | Site:[sname, city]>}]>} 
and is depicted below: 



dname 


loc 


info 










Payroll 


HQ 




ename 


ssn 


dept 








2.11.1. LL LL 1 Emp: 


Bob 




123- 


Payroll 














45- 


















6789 














sname 


city 












Site: 


HQ 




San 


















Jose 














sname 


ssn 


dept 








Emp: 


Sam 




356- 


Payroll 














02- 


















6743 








dname 


loc 


info 










Quality Ctrl 


HQ 




ename 


ssn 


dept 








2.1LLLLLL2 Emp: 


Marilyn 




321- 


Quality 
















54- 


Ctrl 
















9876 
















sname 


city 












Site: 


HQ 




San 


















Jose 














sname 


ssn 


dept 








2.11.1. LLLL3 Emp: 


Qing 




673- 


Quality 
















82- 


Ctrl 
















3845 










dname 


loc 


info 


Sales 


HQ 




sname 


city 












HQ 


San Jose 












ename 


ssn 


dept 








2.1 LLLLLL4 Emp: 


Betsy 


233-23- 




Sales 












6352 














ename 


ssn 


dept 








2.1 LLLLLL5 Emp: 


Brian 


341-69- 




Sales 














0323 










dname 


loc 


info 


Personnel 


Satellite 


0 



Dept: 



Dept: 



Dept: 



10 
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2.11 Union 

The union of two union types, ui © u 2 , is defined to consist of all tags in both types, provided 
that a tag occurring in both ui and U2 has identical types in ui and u 2 . 



10 



Defn. Union operator: 

U ({<r n , r i2 , r in >}, {<r ju r j2 , r jm >) - 



r in > © <rji, r j2 , 



-,r jm >) 



{<r\u r i2 , 
Example 

The union operator is illustrated using the Depts and EmpsSites tables from the 

join example. The operation: 
U (Depts, EmpsSites) 
results in the NCR: 



Dept: 

Dept: 

Dept. 

Dept: 

Emp: 

Emp: 

Site: 

Emp: 

Emp: 

Emp: 

Emp: 



dname 


foe 




Payroll 


HQ 


dname 


loc 


Quality Ctrl 


HQ 


dname 


loc 


Sales 


HQ 


name 


loc 


Personnel 


Satellite 


ename 


ssn 


sal 


Bob 


123-45-6789 


Payroll 


ename 


ssn 


sal 


Marilyn 


321-54-9876 


Quality Ctrl 


sname 


city 




HQ 


San Jose 


ename 


ssn 


sal 


Qing 


673-82-3845 


Quality Ctrl 


ename 


ssn 


sal 


Betsy 


233-23-6352 


Sales 


ename 


ssn 


sal 


Brian 


341_69-0323 


Sales 


ename 


ssn 


sal 


Sam 


356-02-6743, 


Payroll 



The expression AUB, for various types of A and B is illustrated in the following: 
15 L If A:{<Emp:[name, phone]>), B:{<Dept:[name, floor]>}, then AU B has type 

{<Emp:[name, phone] | Dept: [name, floor]>} and denotes their disjoint union 
{i.e., no duplicates are introduced, and duplicate elimination is not needed). 
2. If A:{<Emp:[name, phone] | Mngr:[name, beeper]>} and 

B:{<Dept:[name, floor] | Mngr:[name, beeper]>} then AUB has type 
20 {<Emp:[name, phone] | Mngr:[name, beeper] | Dept:[name, floor]>} and 

means: take the disjoint union of Emp's from A and Dept's from B, and take the 
regular union of Mngr's from both A and B. The output type is: 
{<Emp:[name, phone] | Mngr:[name, beeper] | Emp:[name, phone]>}. We 
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need to do duplicate elimination on Mngr's. If the type of Mngr in B is changed, 
such that the types of Mngr in A and B do not coincide any more, then A U B is 
illegal. 

3. If both A and B have the same type, say {<Emp;[name, phone] | Mngr: [name, 
5 beeper]>), then A U B is the regular union and the output type is the same. 

2.11 Distinct 

The distinct operator removes duplicates: 

10 distinct: {t} -> {t} 

2.12 Aggregates 

Aggregate operators are included in the combo operator. The five aggregates in SQL 
and: count, sum, min, max, avg. Count is treated slightly differently. Let agg be one of 
15 sum, min, max, avg, and let b be the base type to which it applies (b can be int, real, or 
string when agg is min or max, int or real when agg is sum, and real only when agg is 
avg). Consider a union type: 

u = <tagi : ri | ... | tag n< : r n > 

20 

and let ei : ri — > b, . en : r n — > b be expressions. Then the following is an expression: 
agg<tagi/ei | ... tag n /e n > : {u} -> b 
25 Expressions can be used in combo operators. 

Example. The following example uses the NCR: 
Products: {<Indigenous:[name, quantity, category], Imported: [n,q,c]>} 

30 

Where n,q,c stand also for name, quantity, category. The computation of the total 
quantities for all categories is performed in three steps: First, all categories are 
computed: 

35 Cat — distinCt(S <Indigenous -> Cat [category -> c] | Imported -» Cat: [ c ]>(ProduCts)) 

The type is {<Cat:[c]>}. Second, the products are nested by categories: 

GrOUpS = NeSt <Cat:[Prods<Indigenous/($l.c=$2.category)|Imported/($l.c=$2.c)>(Cat, Products) 

40 

The type is {<Cat:[c,Prods:{<Indigenous:[ ...], Imported [ ]>}]>}. 
Third, the sum of all quantities is computed: 
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Answer — E <Cat:[c, total.suin<Indigenous/qiiantity | Imported/q>(Prods)]>(Gl*OUps) 

The type is {<Cat:[c, total]>}. 

5 

3 NCR-QL 

The following illustrates how XML-QL could be mapped into the algebra. However, XML- 
QL works over XML data, not NCRs, so an NCR version is defined of XML-QL ("NCR- 
QL"), that works on NCRs. 

10 The analogy between XML-QL and NCR-QL is the following: 

XML-QL : where-construct 

NCR-QL: from-case-where-construct 

is 3.1 Query 1 

EmpsDeptsSites is the relation defined earlier containing tuples about Employees, Departments, 
and Sites. HOwnersCities is a relation containing tuples about HomeOwners and Cities. The 
following NCR-QL query performs some join between the two: 

From EmpsDeptsSites, HOwnersCities 
20 Case (Emp:[name: $X, ssn: $Y, sal: $Z, phone: $U], HOwner:[lastname:$V, zip:$W]) : 
(Where $X-$V AND $Z > 100000 
Construct EHO:[name:$X,ssn: Y,zip$W]) 
| (Dept:[name:$X, loc: $Y, mgr: $Z], HOwner:[lastname:$V, zip:$W]) : 
(Where $Z=$V 
25 Construct DHO:[name:$Z, dept:$X, zip:$W] 

| (Dept:[name:$X, loc:$Y, mgr:$Z], City:[cityname:$V, place:$W]): 
(Where $Y = $W 
Construct DC:[name:$X,city:$V]) 

30 All combinations of tags from EmpsDeptsSites (defined above) and HOwnersCities (some 
other NCR) listed in the Case statement are inspected, and in each case a different output tag is 
produced. The corresponding algebra expression is: 

E p (EmpSites tX]j Depts) 
where: 

j = <Emp,HOwner/(name=lastname AND sal > 100000)^EHO 
| Dept,HOwner /(mgr=lastname)—>DHO 
| Dept, City / (loc=place) -> DC> 

40 

p = <EHO.[name,ssn,zip], DHO:[mgr^name, name^dept,zip], DC:[name,cityname->city]> 
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3.2 Query 2 

This query illustrates patterns over sets and how they are translated into the algebra. It 
5 roughly corresponds to the XML-QL pattern: 

<products> <product> <name> $n </> 

<orders> <order> <date> $d </> </> 

</product> 
</products> IN Products 

10 where <orders> is a set. The NCR-QL query is more powerful since it handles heterogeneous 
collections of products and orders. 

From Products 

Case (SeattleProduct:[narne:$n, price:$p, ordcrs:$x]): 
Construct 
15 (From $x 

Case (order: [customer: $c, date:$d]): Where $p<100 

Construct usProductDate: [name:$n,date:$d]) 
| (ParisProduct:[nome$n,prix:$p,orders:$x]): 
Construct 
20 (From $x 

Case (euOrder:[country:$c,date:$d]): Where $p>35 

Construct euProductDate:[name:$n ? date:$d] 
| (usOrder:[city:$c,date:$d]): Construct importProductDate: [name :$n, date :$d]) 

25 Here Product has type (base types omitted): 

{<SeattleProduct: [name,price, orders: {<order: [customer,date]>}] | 

ParisProduct: [nome,prix,orders: (<euOrder: [country, date] | 
importOrder:[city,date]>}]>} 

30 While XML-QL had a single pattern, nested patterns in NCR-QL are needed to match over 
nested sets. The NCR-QL query is translated into the algebra using a match operator: 

£ p (^(Products)) 
where: 

35 m = <SeattleProduct:[name:_, price:_, orders:unnest{<order:[customer:_, date:_]>}] 
| ParisProduct: [nome:_, prix:_, orders: unnest{<euOrder: [country :_, date:_| 
| usOrder:[city:_, date:J>}]> 

Note that Q m (Products) has type: 
40 {<SeattieProduct:fname,price,orders:<order:fcustomer,datel>l | 
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ParisProduct: [nome,prix,orders:<euOrder:[country,date] | 
importOrder : [city, date]>] > } 



Which is the same type as for Products, with inner braces erased. It normalizes to: 

5 {<SeattleProduct.order:[name, price, orders. customer, orders. date] 
| ParisProduct. euOrder:[nome, prix, orders, country, orders, date] 
| ParisProduct. importOrder. [orders. city, orders. date] >} 



Hence, p is: 

10 

<SeatUeProduct.order/price<100 — > UsProductDate: [name — > name, orders. date -> date] 
| ParisProduct. euOrder/prix>3 5 -> EuProductDate: [name -> name, orders, date -» date] 
| ParisProduct.importOrdcr — > ImportProductDatc: [name -» name, orders. date -> date]> 



15 3.3 Query 3 

The nesting in NCR-QL is illustrated using subqueries. 
From Products 

Case (product: [id:$x, name $n, price :$p]: 
(Where $p< 100 
20 Construct ProductWithOrders: [name:$n, 

orders: From Orders 

Case (order: [pid:$y, quantity:$q, date:$d]): 
Where $x=$y AND $q>5555 
Construct order: [date :$d] 

25 ] 
) 

The types are (with base types omitted): 

30 

Products: {<product:[id, name, price]>} Orders: {<order:[pid,quantity,date]>} 
The algebra expression equivalent to Query 3 is: 
35 Ep(Nest n (Products, Orders)) 

where n is: 

n = <product: [orders: <order/id r=: pid>]> 

40 

and p is: 

p=<(product/price< 1 00 -» ProductWithOrders) : [name, orders : { <order/quantity>5 555: [date] > } ]> 
45 Notice that Nest n (Products, Orders) has type: 
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Nest n (Products, Orders) : {<product:[id, name, price, orders: {<order: [pid, quantity, date]>}]>} 

3.4 General Form of Queries 

5 A general form of algebra expressions for NCR-QL (and, hence, XML-QL) queries is: 

Z p (Nestni (Join! , Nest^C Join 2 , . . . NcsU.i ( Join k _! , Join k ) ...))) 
where: 

10 Join, =Q mU (Rii) XLii ^mi2(Ri2)[Xjii ■■■ 

J0in 2 = OnSl^l) IX3j21 On22(R 2 2) \X\fll ■ ■ ■ 

Join k = OnkiCRkOltXOjki ^(Rd^><ljki ••■ 

4 Algebraic Laws 

The following three kinds of algebraic laws are formed: 

20 • Push selections and projections down. Selections and projections are captured by 

the Combo operator, 2 P , hence laws are needed that commute Combo with other 
operators 

• Join reordering: associativity, commutativity. 

• Join-nest associativity. 

25 

4.1 Laws that Push Combo (^Selections and Projections) Down 
4-1-1 The Combo-Combo Law 

Let p : tl — > t2, and q : t2 -> t3 be two p-formers. Then: 

30 S q (S p (R)) = S r (R) (the combo-combo law) 

Here r is a new p-former defined as r=ppcompose(q,p), by induction on q first, and, where 
needed, by induction on p second. 

/* q = identity */ 
ppcompose(_, p) = p 
35 /* q = record p-former */ 

ppcomposeflXb^ ->ci):qi, (b lk -^c k ):q k , c k +i:ei,c k+2 :e 2 ,. . .,c r :e r _ k ], _} = [(\ -»ci):qi, 

(b lk ->c k ):q k , c k+ i:ei,c k+ 2:e 2 ,...,c r :e r . k ] 
ppcomposeflXb^ -»Ci) qi, (b lfc -»c k ):q k , c k+ i:ei,c k+2 :e 2 ,. . .,c r :er. k ],[( a^ ->bi):pi, 
(a Jm ^b s ):p s , b s+ i:fi,c s+2 :f 2 ,...,b m :f m . s ] = 
40 [(a ->Ci):ppcompose(q u p^ ), (a^ ->ct): ppcompose(q k , p Ijt ), 
ct + i:f ll+1 _,,ct +2 :f li+2 _ 5 ,...,c k :f lk _,, 
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Ck+i:e, op, c k+2 :e 2 op,..., c r :e r . k op ] 

/* here {ji, ...J m > d {1, 2, n) and {i u i k } c {1, 2, ...,m), with ii < i 2 
<...< it <= s < i t +i < . . . < ik <= m, 

p is the second p-former, p = [( a J( -^bi):pi, (a Jm -^b s ):p s , 

5 b s +i:fi,c s +2:f2,. - ,b m :f m - s ] 5 

and e o p means "apply the p-former p first, then e" and is defined below */ 

/* q = variant p-former */ 

ppcompose((tag7c' -> tag M ):q, J = (tag/c -> tag'):q 
ppcompose((tag/c' -» tag M ):q, (tag/c -> tag'): p) = 
10 (tag/(c and c'°p)^ tag'):ppcompose(q,p) 

/* here c'op is defined below and means: apply p first, then check c* */ 

/* q = union p-former */ 

ppcompose(<qi | . . . | qk> , „ ) = <qi I ■ • I Qk> 

ppcompose(<qi | | qk> , <Pi I I Pm>) = < I ppcompose(qi, Pj) | > 
15 /* here each qi is paired with all those pj that have an output tag that matches 
the input tag in q* : according to the definitions there could be one ore more */ 
/* q = set p-former */ 
ppcompose({q}, _ ) = {q} 
ppcompose({q}, {p}) = {ppcompose(q,p)} 

20 

Composition of a p former with an expression, e ° p , and a p-former with a condition, 
c«p, are defined. In both cases, the expression (e) and the condition (c) have a single 
record argument, {i.e., only use $1, which, by convention, may be omitted), while p is a 
record p-former, p - [(a^ -> b,) : p h ,...,(a lfc ^b k ):p k ,C! :e!,...,c p :e p ]. 

25 

epcompose($Lbj, p) = $1. a 
epcompose($l .Cj, p) = ej 

epcompose(e op e\ p) = epcompose(e,p) op epcompose(e',p) where p is +, -, *, /, 
30 epcompose(f(ei,e 2 , ), p) = f(epcompose(ei,p), epcompose(e 2 ,p),. ) 

cpcompose(e op e\ p) = epcompose(e, p) op epcompose(e',p) where op is <, >, <= 

>= 

, ... 

cpcompose(<tag:[ai:ei, a n :e n ]> IN e, p) = <tag:[ai:epcompose(ei,p), a n : 
35 epcompose(e n ,p)]> IN epcompose(e,p) 

cpcompose(exists(e), p) = exists(epcompose(e,p)) 
cpcompose(true, p) = true, cpcompose(false, p) = false 

cpcompose(ci and c 2 , p) = cpcompose(ci, p) and cpcompose(c 2 ,p) same for or, not 

40 Example. Let p = <Emp/(sal>50000)^HighEarner:[name^richName:_] | 
Dept/(mgr= "Betsy")->BetsyManages:[name^name: J | 
S ite/(true)^S ite : [name^name :_, city ^city :_]> 
Define R= Z P (EmpsDeptsSites) 
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Let q = <HighEamer/(like(richN^^ -> name: J | 

BetsyManages/true -» Betsy [name -> name: J | 
Site/(city=" Seattle") HighEarner:[name -> name: J> 

5 

And define R' = E q (R) = E q (Z P (EmpsDeptsSites)) 
Then R' = Ep P composc(q,p)(EmpsDeptsSites), where: 
ppcompose(q,p) = 

<Emp/(sal>50000 and like(name, M %Smith%")) -> HighEarner:[name name: J | 
10 Dept/(mgr="Betsy M and true) -» Betsy: [name -> name: J | 

Site/(true and city-" Seattle") -» HighEarner:[name -> name: _ ]> 

4.1.2 Applications of the combo-combo law 

15 1 . Commuting order of selections. Consider an example with simple combo 

operators: 

£°<Emp/(sal=20000)>(£ <Dept/(mgr-"Smith")>(R)) = 
E°<Dept/(mgr="Smith")>( 2 <Emp/(sal=20000)>(R)) 

To prove that we expand the simple combos into combos, then apply the combo- 
20 combo rule. The left hand side becomes: 

£°<Emp/(sal=20000)>(£ <Dept/(mgr="Smith")>(R)) = 

~ £<Emp/(sal=20000) I Dept _ | Other: _>(£<Emp._ | Dept/(mgr=" Smith") | Other. >(R)) 
= E<Emp/(sal=20000) | Dept:/(mgr=" Smith") | Other:_>(R) 

The right hand side is similarly : 

25 £°<Dept/(mgr-"Smith")>( 2 <Emp/(sal=20000)>(R)) — 

= £<Emp:_ I Dept/(mgr="Smith") | Other. >( £<Emp/(sal=20000) I Dept | Other:_>(R)) 
— S<Emp/(sal-20000) | Dept:/(mgr="Smilh") | Other: >(R) 

Hence the two are equal. 
2. Commuting inner selections. 

30 S^Dept.tprojcct^^rgent/Cdeadline^^lO/lO^OlO") >}]>(? <Dept [ pro ject:{<urgent/(budget<= 10000) 

> }] >(R)) = 

= 2 <Dept: [project: {<urgent/ budget<=10000)>}]>(£ <Dept* [project: {<urgent/(deadline>=" 10/1 0/20 10") 

>}]>(R)) 

Indeed, take the left hand side and expand the simple combos into combos, then 
35 apply the combo-combo law 

„() ✓ yO 

^ <Dept: [project {<urgent/(deadline>="l 0/1 0/20 10") >}]>V^ <Dept [project: {<urgent/(budget<= 10000) 

»]>(R)) = 

= 2<Emp: | Dept [name , mgr: , project {<urgent/(dcadline>=" 10/1 0/20 10") | normal: _>}]>(^<Emp._ | 
Dept.[name: , mgr: , project {<urgent/(budget<= 10000): | normal: >}]>(R)) — 
40 = S<Emp. | Dept : [name: , mgr: , project: {<urgent/(deadline>=" 10/10/2010" and budgct<= 10000) | 

normal:_>}]> 
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The right hand side is treated similarly and results in the same expression, hence 
they are equal. 

3. Pushing predicates to sources. Consider a selection on the predicate (name like 
"Smith%"). The source supports some predicates, but not this one. Suppose it 
5 supports the predicate (name like "%Smith%"). The predicate is: 

c = (name like "Smith%") 
the source predicate is: 

c s = (name like H %Smith% M ) 
The optimizer knows the following implication: 
10 c => c s 

which is equivalent to: 
c = c and c s 

Hence it can perform the following optimization: 

£°<Emp/(name like "Smith%")>(R) = ^ <Emp/(c)>(R) = ^ <Emp/(c and cs)>(R) 
15 = ^ <Emp/(c)>( £ <Emp/(cs)>(R)) 

= £ <Emp/(name like "Smith%")>( ^ <Emp/(name like 

"%Smith%" )>(R)) 



20 

4.1.3 The Combo-Nest Law 

Let n : : u u u 2 ^ube an n- former and p :: u ^ u- be a p-former. Then the following 
holds: 

25 Z p (Nest n (R, S)) = S p3 (Nest n < E pl (R), Z p2 (S))) (generic combo-nest law) 

where pi, p2, p3 are p-formers and n' is an n-former to be described next. The following 
can be chosen: p3=p, n-n, and pl=p2-_, and the identity holds. But, pi and p2 are 
chosen to do as much as possible of the work that p does. 
30 Let ui=<tagii:rn | ... tagi n :ri n >, u 2 =<tag 2i :r 21 | ... tag 2m :r 2m >. 
The n-former n has the form: 

n = <tagn : [bi : <tag 2 i/cii | . . . | tag 2m /cim>] | i = 1, . . . , n> 

The p-former p has the form: 

35 p = <pi | ... | Pk> 

where: pi = tag lj( / Ci' tag^qi, c/ : r lj( <g> [b^ :{u 2 }] -^bool, i = 1, k, 

where {ji, j k } c {1, 2, ...,n) 

Combo-nest law 1: Assume that, for some i=l,. . .,k, the predicate c/ ignores the nested part 
40 (formally: $1 . bj does not occur in q'), and that qj is the identity p-former. That is: 
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Pi = tag ]Jf / Q f tag3i:_ 
Define: 

Pi- tag lj( / Ci' -» tag lj( :_ /* i.e., tag^ replaces tag 3 i in pj */ 
pi =<Pi> 

5 p3 = <pi | . . . | Pi-i I tag lj( -> tag 3i :_ | Pi+i I ... Pn> 



The combo-nest law is: 

Lp(Nest n (R, S)) = Z p3 (Nest n ( Epi(R), S)) (combo-nest law 1) 
Here n-n and p2 = 

10 Combo-nest law 2: Assume that, for every i=l , . . . ,k, the predicate Ci' only depends on its first 
argument (i.e. , it ignores the nested part, bj ), and that q t leaves all fields unchanged except 
for bj where it applies a selection, and that, moreover, that selection is the same for all 
i=l , . . . ,k. More precisely: 

15 where . . . contains only identity p-formers, i.e., a-^a:_ for attributes a, and where 
r= <tag 2 i/c 1 i"| ... | tag 2 m/Cim"> 
is a selection that is the same for every i=l , . . . ,k. Define: 

Pi 1 - tag lj( / c^ -> tag lj( :_ for i = 1, . . k 

/* i.e., _ replaces qi and tag lj( replaces tag 3 i in pi */ 

20 pi =<pi | ... | pn> 

p2 = r 

p3 = < tagiji -> tagi 3 i :_ | . . . | tagi jk -> tagi 3k :_ > 
The combo-nest law is: 

25 Z p (Nest n (R, S)) = Z p3 (Nest n ( E pl (R), S p2 (S))) (combo-nest law 2) 
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4.1.4 The Combo-Join Law 

Let j :: ul, u2 — > u be a j-former and p::u — > u' be a p-former. Then the following 
holds: 



where pi, p2, p3 are defined below. 
Notations: 

10 

j =<tagli,tag2j/cij ^tagij* | i = 1, n J - 1, m> 
p= <tagy'/cj'^ tagy" : q ij I i = 1, . . . ,n, j = 1, . . . ,m> 

Here Cy : ru x r2j — » bool is the join condition, while c,/: ri t x r 2 j — > bool is a selection 
15 predicate. Not all combinations of tags tagy' must occur in p, but to simplify notations 
they are included. Assume that c l} \x,y) = dij(x) AND eij(y) AND fij(x,y). That is dij(x) 
contains all conditions that only inspect only values from the left join operand, e y (y) 
those conditions that only inspect values from the right join operand, while £j(x,y) 
contains conditions that inspect values from both operands and cannot be separated. The 
20 conditions on the left operand are independent of j, i.e.,'. 



and similarly: 

25 

eij(x) - e 2j (x) = . . . = e nj (x) = ej(x) for j=l , . . , m 

This can often be achieved, by manipulating boolean conditions, factoring out the 
common parts and pushing the specific parts into fjj(x,y). Then define: 



5 



Z P (R [X] j S) = S p3 (S pl (R)[x3 j Spa(S)) (the combo-join law) 



du(x) = d i2 (x) 



dim(x) = d x (x) 



for i=l, n 



30 



pi =<tagli/d 1 ^tagli,. ,tagl n /d n ^tagl n > 
p2 = <tag2i / ei -> tag2i, , tag2 m / em -> tag2 m > 
p3= <tagi//fij-> tagij" : q ij | i = l,...,n, j = 1, ...,m> 



35 



4.2 Laws that commute joins and nests 



40 



4.2.1 Join Associativity and Commutativity 



Join commutativity holds: 
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R jS = S jR (join commutativity law) 

Join associativity: 

5 Ji S )DX]j2 T = Rt><]j3 (S [X] j4T) (join associativity law) 

holds for various choices of the j-formers j3 and j4. 

In R P><3 ji S only a subset of all pairs of tags need to have join conditions. To simplify 
10 notations, however, each join considers all pairs of tags. Hence: 

j 1 = <tagn, tag 2j / ci y ^ tag4 y | i = 1, n, j = 1, m> 

j2 = <tag 4 ij, tag3k / c 2 ijk -> tagij k | i = 1,. n, j = 1, , m, k = 1,. p> 

15 The condition c 2 yk looks at three records: x from R, y from S, and z from T. 
Decomposing it into two pieces: 

c 2 ijk(x,y,z) = c 3 ijk(x,y,z) AND c 4 jk(y,z) 

20 such that the part inspecting only y and z is the same for all i=l, . . . ,n. That is, in order to 
define c 4 jk(y,z) we inspect each condition C2ijk(x,y,z), . . . , C2njk(x,y,z) and factor out what 
all of them do in common with y and z. Then define: 

j4 = <tag 2 j, tag 3 k / c 4j k -» tag 5 jk | j=l , . . . ,m, k = 1 , . . . ,p> 
25 j3 = <tagi i? tag 5j k / c 3 ijk -> tagijk | HI , ,n, j=l , ,m, k=l , ,p> 



4.2,2 The Join-Nest Rule 

30 The following holds: 

R X] ji (Nest nl (S, T)) = Nest n2 ((RXl & S X T) Goin-nest law) 

provided that j 1 looks only at the S-component in Nest„i(S, T). In that case, j2 is "the 
35 same" as j 1, except that it does not get to see the nested attribute, which j 1 did not use 
anyway. Similarly, n2 is "the same" as nl, except that now it gets to see an R 
component, which it ignores. 

From the above description, it will be appreciated that although the specific 
40 embodiments of the technology have been described for purposes of illustration, 
various modifications may be made without deviating from the scope of the 
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invention. Accordingly, the invention is not limited except by the appended 
claims. 
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